Sync Pane 1 bug/change from v12 + 1 improvement suggestion

In the order as title:

I use mirroring a lot (dest is 1:1 copy of source). When I compare 2 folders (with 0 changes) in Sync Pane with "hide unaffected files" and sync finds no changes, in v12 both source & dest would stay empty after I confirm. v13 first shows empty tabs first, but as soon as I click somewhere it starts populating the tabs in mixed folder view; the tabs contents do not change btw, i.e. no "new sync needed". I prefer the v12 behaviour, i.e. let the tabs stay empty after comparison and see no reason for the new one. Was this intentional? If yes, why?

Now on to my suggestion: If hide unaffected files is selected (or a new option if you like), do not switch to mixed folder views in both panes before the comparison starts, instead switch to mixed-folder view and show affected files only after the comparison is done. If there are columns (as in my case script-computed Status) in mixed view, this just causes extra disk trashing without any benefit whatsoever. If both dirs have a large amount of files, this gets worse and worse even if I turn off all extra columns, and in some cases even makes DOpus "milky glas" unresponsive if the folder have a large number of files. Delaying the mixed folder display until after the comparison would definitely speed it up even more.

Yes it was. It was felt that being confronted with a completely empty display in the event that no work needs to be done was potentially confusing.

Unfortunately the Sync tool is designed around Flat View, and requires that the contents of sub-folders be read before the comparison stage can begin.

You should be able to configure the Synchronize folder format to exclude all but necessary columns though.

If it was deliberate no problem.

This definitely works fine if the fileset is small and both drives are very fast. However, this is also slowing down the comparison for other use-cases, like old-school spinning portable/NAS disks, USB sticks, SD cards, etc. If the drives are already spinned up and the same set of files are used, in tools like Syncback or BeyondCompare recursive comparisons are done in 2-3 secs & 3-4 secs respectively, and in DOpus in 25-30 secs, of which first few seconds make the UI literally unresponsive (see 'Not Responding' @ 1:43 in titlebar), because of the visualization overhead I reckon. My use-case is usually mirroring certain folders, where usually <10% files change, and if only 1% files have been changed, the rest 99% must be still "shown" and discarded afterwards. IMHO this is unnecessary, independent of custom columns, which I completely disabled for this. This is why I suggested to bypass this only if "hide unaffected files" is active. But if it cannot be changed, so be it.

But I don't understand this yet: When both folders are in FlatView and fully synced and read, a second comparison takes the same amount of time, whereas other tools finish the comparison almost instantenously. The disk caches are clearly filled and other tools become faster, but DOpus comparison is still at same speed. If DOpus bypasses disk-caches and rereads everything, ProgressBar definitely adds its overhead on top. I don't know, maybe using the info off Everything with a new checkbox could speed things up, and only ProgressBar overhead would be left.

The technical dependencies are fully understandable and I'm not expecting you guys to change it soon, let alone overnight. Fact is though, compared to other tools, DOpus syncs are slow and I'm just throwing ideas out to make it better.

ps: In the video, D: M.2, F: internal HDD, H: external SSD. F spinned up and drives are read before. If the disk is spinned up but directories are not yet read before, the 25s DOpus needs becomes twice long, not so much with SyncBack or BC.

You have a filter set - how is that defined?

fullpath nomatch .git
#and date match modified within 1 day
#and size match = 0 bytes

I disabled the filter and re-run it for the exact same case, still 25s, no change.