I have a folder structure with about 12.000 images. When I turn on flat view I can scroll through all images fluently. When I type a search into the search bar and get some images as a result that is also fine. When I delete the search after that I have to wait for 30 seconds and DirOpus is not usable at all. After that I can use it, but the little "circling icon" still is turning for another 30-40 seconds.
I had activated "load all thumbnails automatically" (translation from German). If I switch this option off, I have delay of maybe 1s which is totally acceptable, but when I want to scroll through the image list, of course I do not see the thumbnails which makes searching in this large number of images quite problematic.
Is it not possible to keep the once loaded thumbnails in a cache so that searching and deleting the search within the flat view would not cause another long delay? Also automatic loading of a flat view could be done in a background process so that it would not block DirOpus for other operations?
I have assigned two tags to three images of the 12.000+ images in the directory structure. After that I simply type the tag name into the search bar. The three images are correctly shown. After that I click the little "x" to end the search in the search bar. Then the long refresh time starts.
Each snapshot shows different things going on, so it doesn't look like things are getting tied up in any one place. There are some things that they point to which are worth a try:
Does closing the folder tree (before closing the search) make a difference? Several of the snapshots indicate the tree is being updated, which could make it a factor. But several of them don't show that happening, either, so I'm not sure if it's really the bottleneck. Worth a try, though.
Disabling/removing Listary, Fences and MacType may be worth a try. None look likely to be the cause, but they have hooks in the stacks of a lot of the snapshots (especially the ones where the tree is updating), which means they could be involved in some way. MacType also looks like it could affect UI speed in general if something goes wrong with it. But these are just things worth a try, not definitely involved in the problem.
Anything else that hooks/modifies how other programs behave is also worth ruling out. In several cases there is a thread where one hook is waiting for the next hook in the chain to be called, which may mean I can only see the names of the innocent hooks and not the name of the next one which is the one that's actually causing the delay.
Disabling antivirus scanning may also be worth a try. The one thing common to all of the snapshots is there is file information/metadata being retrieved on background threads. That would not normally cause a slowdown, but sometimes antivirus can pause the entire process when one thread opens a file that the antivirus wants to scan.
What is very clear: the flat view in one tab with several 10K images is the problem. When I exclude this from my standard lister and start DirOpus, then it is ready to go in less than a second and quite responsive. When I turn on the flat view with automatic loading the thumbnails then about two minutes my whole system is laggy, even for other applications. I have disabled Fences, Listary, MacType and also deinstalled Iolo System Mechanic.
My guess is antivirus in that case, as it's one of the few things that can slow down everything at once (depending on how the antivirus is written and if it queues up all scans system-wide instead of having a separate queue per process).
It could also be very low memory, very heavy storage access or very high CPU usage (on all cores), which Task Manager should show if that's the case. A thumbnail generator going wrong could cause those.
I have disabled Windows Defender as well as Windows indexing (except for Outlook). There is more than enough memory. During the wait time CPU usage is constant 100%. I have set 2 threads for thumbnail generation. In the attached Task Manager screenshot you can see that I have to wait for almost two minutes.
If that would occur one time then I could endure it, but any time I leave this folder and come back later this process starts again and takes this time again although I have activated thumbnails cache. I do not understand this.
In this context I was astounded again. As for trying to optimise performance and reduce danger of CPU overload I disabled Windows indexing only to recognize that now in that specific folder branch view we are discussing here I cannot search quickly any more for specific tags. So Windows indexing is also driving the tags search within DirOpus?
Is the issue that closing the search tab takes a long time?
Or is the issue that generating thumbnails for everything in the search results takes a long time?
(Or both?)
What type of files are involved? (As in file formats, rough dimensions.)
I'm getting a bit lost in the different things here, and now we also seem to be talking about metadata tags and search indexing. Let's focus on one thing at a time, please. If there are other issues to the one in the thread's subject line, please start separate threads for them.
Some quick information, in case it saves the need for additional threads:
Regarding Windows Search indexing, it has no effect whatsoever on what Opus displays or caches, other than in terms of which files are/aren't included in the results if you ask Opus to run a Windows Search query.
Regarding thumbnail caching, it won't be done for thumbnails which come from the Windows shell (as the shell caches its own thumbnails and there's usually no reason to cache them a second time). It also won't be done if a thumbnail generated very quickly (if it can be regenerated as quickly as it can be read from the cache, then there's no reason to use space caching it). Everything else should end up in the cache. It would take a huge number of images to fill an 8GB cache, so it only using 466MB currently isn't alarming in itself.
It can also depend on the type of drive the files are on, and your configuration. In your screenshot, it's only configured to cache thumbnails for images on local drives, not network or removable drives.
(Edit to add:) The thumbnail cache does not store other metadata for files. It isn't a general metadata cache.
The main problem is the long thumbnail generation / refresh time when I create a new tab with that flat view of that directory. The same happens, if I save the lister layout with that specific directory structure as a flat view. The same also happens when I do a search and quit this search. All this triggers a long thumbnail generation process. This is the main problem.
I disabled shell thumbnails, but that also does not seem to help much.
The directory in question consists mostly of pictures and movies from my smartphone, size of pictures is roughly 4-6 MB, some up to 16MB. Videos are 20 - 100MB, a few up to 300MB
I'm guessing it's only the videos which are slow. Is that correct?
Something that may help: Configure the Opus Movie plugin to not generate thumbnails. It may be trying to generate movie thumbs and taking a long time before failing, at which point Opus will ask the shell for them.
That could be the cause of the delay, and would explain why they're slow even when cached (by the shell).
To do that:
Go to Settings > Preferences / Viewer / Plugins.
Select Movie, click Configure.
Turn off Generate thumbnails and click OK in both dialogs.
If the files are still slow, what happens when you view the same files in File Explorer? It should use the same cache for video files.
