No encryption of course, but it *does* calculate rolling checksums. Quoth the man page:
Note that rsync always verifies that each transferred file was
correctly reconstructed on the receiving side by checking a
whole-file checksum that is generated as the file is trans‐
I think that means both the client and server sides checksum the file,
even if rsync is running locally. Thus cpu usage, etc.
Most of the reason to use rsync locally is its nice interface. It should be possible to have a rsync varient that omits using the checksums, and simply overwrites the destination file always, like cp -- but with the rest of the rsync interface left intact. That should be much faster on some hardware.
For example, I have an arm fileserver that I used to use to rsync data to an external usb disk. It turns out to be faster to run rsync on a faster (intel) client, even though it has to get the data over NFS..
Since md4 tends to be 50% or so faster than md5, running rsync with --protocol=29 may also be a nice way to speed it up.