File Comparator can be Inefficient

[therube]

In some instances comparing files (File Comparator, Ctrl+Sh+C) on the same volume can be highly inefficient/disk intensive.

For instance, I have two XP ISO's (so ~600 MB each). Each defrag'd (verified with contig.exe -v -a), yet an attempted compare runs extremely slowly with the lots of "flutter" (*not the correct terminology) in the disk read/write heads as they jump back & forth.

In cases where this happens, I don't believe it is necessarily a function of the file sizes involved.

(& irrespective of 2.52's "Up to 7x faster Compare Directories (by content) command for files on the same disk").

Oops. Quoting myself, but here I go again. Mixing up two different features. File Compare vs. Compare Directories (with Content selected).

(Later I'll try to try the Compare Directories command to see if it responds similarly.)

[therube]

File Compare vs. Compare Directories do act differently.
Guessing that Compare Directories is using a larger block size. So less head movement.

File Compare sounds like a non-stop machine gun.

Compare Directories sounds ... like a machine gun with a slight stutter step.

(Hows that for a description!)

[SelfMan]

This is natural, because filecomparator works differetly.
It does not only look if the file is different it also checks where it is different.

[therube]

Somewhat.

(In my case, both files are the same.)

Comparator would have to read each file fully in order to enumerate the differences. (Though I'll assume there is a limit set to that too <32K ?>, after which everything would be considered not matching.)

Compare Directories (Content) would stop after the first mis-match between the files (or less if the file sizes are not the same).

Since my files are identical, both Comparator & Compare Directories would need to read through both files entirely.

I'll assume they must be using different algorithms, block sizes & whatnot, or I would hear similar "noises".
As it is Comparator is taking longer, & making much more "noise", so perhaps its' algorithm could be enhanced.

[Jan Rysavy]

We will look into this issue, thank you for reporting it. The File Comparator plugin and Compare Directories command are different code so it is very likely there will be different buffers size, etc.

[Jan Patera]

I'll assume they must be using different algorithms, block sizes & whatnot, or I would hear similar "noises".

Binary File Compare (in the plugin) uses memory mapped files with 512KB windows.
-> It is on Windows to decide the size of blocks that are read into memory at once.

[Petr Solin]

We have optimized Compare Directories recently (in version 2.52 beta 2 in Aug 2009). It seems File Comparator needs something similar when you use it to compare such big files.

[Jan Patera]

We have optimized Compare Directories recently (in version 2.52 beta 2 in Aug 2009). It seems File Comparator needs something similar when you use it to compare such big files.

Binary File Compare was just optimized as well. Wait for the next version of Salamander (AS2.53b1/2.53).

[therube]

PB38 + Binary compare uses buffered files when scanning for differences, instead of memory mapped files. It is up to 7x faster when comparing two files from the same disk.

Much improved.