Why is the comparison speed different?

[ksg]

When the file comparison is started (before that there was already synchronization and exiting the When the file comparison is started (before that there was already synchronization and exiting the program), the comparison speed is the same. If, after the first time, you run the comparison a second time (without synchronization and exiting the program), then the comparison speed will be many times faster. Why is this happening and what is the reason? Is it possible somehow to do so that there is always such a high speed of comparison?
(Google Translate).

[xCSxXenon]

This is best answered by Zenju, but I believe FFS uses a temporary db file to keep the current status and then it only has to detect changes from then on. Exiting the program removes that

[Zenju]

If, after the first time, you run the comparison a second time (without synchronization and exiting the program), then the comparison speed will be many times faster.

The operating system is buffering all file I/O.

All data related to file I/O is buffered in RAM, so the second access won't touch the disk and be super fast.

Now if you start a sync, all the valuable directory traversal data sitting in the OS buffer will be overwritten with rather useless (from your point of view) file contents of the copied files. So the next comparison will be slow again (= unbuffered by OS)

Is it possible somehow to do so that there is always such a high speed of comparison?

Buy more RAM and don't restart the PC.
(But even then: the OS buffer will eventually be overwritten because it's a FIFO queue).

[paolog]

according to this post, the comparison information is stored in RAM and consequently lost when restarting the PC. Is there any way of writing the comparison information from RAM to a file that can then be reused and updated by FFS each time it does a comparison? That would avoid starting from scratch each time and would guarantee a great speed each time! Other than that, FFS is awesome!

[Plerry]

@paolog
Your proposal only makes sense if you could be absolutely sure no changes have occurred in between the previous comparison session, of which the results are stored in said file, and the new/resumed comparison session.
But how could you be sure?
Right! Run a new full compare.

[ksg]

You can create a service that runs in the background and constantly updates the FFS file. Then we wouldn't have to wait long.

[paolog]

@Plerry
thanks, I'd agree with you if I had said "replaced," but I said "reused and updated" - that is, FFS would start from where it left the last time, just like it does when you compare the 2nd time (not the 1st!) within the same PC session. I hope I'm clearer this time around?

[xCSxXenon]

You can create a service that runs in the background and constantly updates the FFS file. Then we wouldn't have to wait long.

But then your PC is wasting resources constantly comparing data AND it is taking buffer space away from other processes that need it more for realtime use.

@Plerry
thanks, I'd agree with you if I had said "replaced," but I said "reused and updated" - that is, FFS would start from where it left the last time, just like it does when you compare the 2nd time (not the 1st!) within the same PC session. I hope I'm clearer this time around?

This is more related to being able to pause a comparison, which has been discussed more appropriately in other threads. The whole point Zenju made is that running a comparison causes the OS to cache the needed data in RAM, which is why the following compares are faster. Saving the comparison info in a file isn't going to speed anything up because that file is going right back onto the storage device anyway! If the comparison info is "on disk", it's just wasting space at that point

[paolog]

@xCSxXenon
ok, that clears it, many thanks for your explanations!