"Verify file checksum on copy" is 5x-7x slower than (g)rsync
Using the live session of Xubuntu 24.10 and copying a large ~4GB file from one location in RAM to another, it takes nearly 60 seconds if "Verify file checksum on copy" is set to always.
Conversely, doing the exact same copy operation in (g)rsync results in the process only taking 9 seconds.
(for reference, doing a standard copy from one location in RAM to another without using (g)rsync and with "Verify file checksum on copy" set to never only took around 2 seconds, if not less)
Video demonstration:
As depicted in the video, testing the time it took for various hashing algorithms in gtkhash, I noticed that crc32 was nearly identical to how long (g)rsync took which made me think that's what it was using, while the closest I got to Xfce's "Verify file checksum on copy" was SHA256 or SHA512 those algorithms still took around half of the time.
While doing the testing depicted in the video when I was monitoring CPU using with a 3core/3thread CPU, my theory was that (g)rsync was performing a crc32 hash on both the source and destination in parallel (one per CPU core) while Xfce's "Verify file checksum on copy" was performing SHA256 or SHA512 sequentially (the latter most obvious due to how it would fully peg only a single core to 100%).
Even though performing the task in serial with only one CPU thread may in fact how Xfce's "Verify file checksum on copy" does it, this cannot be the case for (g)rsync because, even when the PC itself was configured to only expose 1core/1thread, (g)rsync still took the same amount of time as when it had 2+ CPU cores available.