I need some help with Opus slowdown. File operations (copy/delete) are still very fast, provided that one has the patience to get there. But everything else that includes navigation has become painfully slow. Opening a new lister takes ~20s, opening a new tab in a lister or switching from one tab to another (or between the source and destination panes) takes 1~2s, entering/refreshing a folder is also unusually slow regardless of the number of files and subfolders there. All these things were almost like an instant before.
Removing and reinstalling Directory Opus seems to remedy this issue but as soon as my config is restored all goes back to snail-mode, so I'm afraid my custom settings might be the root cause
Please try making some process dumps using Task Manager while the slow-down is happening. If you send them to us we might be able to tell you where the slow-down is coming from and save you having to go through all of your configuration.
Here's how:
While it's happening, please go to Task Manager, then the Details tab, right-click dopus.exe and select Create Dump File.
Do that 4 or 5 times, and it should create something like:
Okay, I'm trying, hard. I've captured a few when starting Opus/new lister. Most of them were about ~200MB, except on which got rather large (789MB??, ~3.5x as large as the others). That was the easy part. I failed at capturing anything that takes eg. 1-2s instead of the few miliseconds it used to. I'm not fast enough to init the operation, switch to Task manager and request the dump. I got another dump that had started after beginning to refresh my D: partition and completed after the refresh finished.
I hope that would prove enough to narrow down the list. I peeked at the preferences but that list is HUGE. I simply cannot afford the time to check each and every one of them. It also seems hopeless to rebuild my config from scratch. 6 dump files, summing to 1.78GB, compressed to 805MB. I doubt that would make any email servers happy. May I email a download link to the above email instead?
I've shared the folder containing the dumps and the config backup and sent the link in an email. The largest dump and the config are still uploading, Google estimates the time remaining to be 1hr 20min. My upload bandwidth is, well, rubbish
My guess is that Windows 10 has messed up your graphics drivers, as all of the dumps indicate delays when creating bitmaps or loading icons, and Windows 10 has a habit of doing this with drivers, often during the larger updates (Creators Update, etc.).
I recommend downloading & installing the latest drivers for your GPU, then reboot and see if the performance issue is still there.
@Leo, I tried updating drivers but Windows reported it was already using the "best" possible driver. It is usually a healthy thing to give a certain level of doubt to anything Windows says but everything else seems to be operating normally so I decided to give it some credit there. Then I gave a try what @auden said and now it seems to be working normally again. Speed is (sort of) back to normal. However, I guess that setting (setting value of Auto from 1 to 0 in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Thumbnail Cache) was set to 1 with reason. I'm afraid there might be some unwanted side-effects by turning it down to 0.
I have been running with the registry fix for some weeks now without any ill effects that I can detect. The problem is apparently caused by a bug that causes the new version of Windows 10 to delete its thumbnail cache when it reaches quite a small number of megabytes, thus causing the thumbnails to be rebuilt over and over again.
It cripples the computer.
@Leo, yes, keeping drivers up to date, and not believing everything Windows says is a general rule of thumb, and I'm surely going to follow that road.
Nevertheless, here's an update that might interest you as well, @auden. It looks like that feature of Windows required a "reboot" on its own. Typical Windows solution of the old times. If something goes bad, restart something. It might not do it next time.
When I disabled it, Opus returned to its original speed. I downloaded the latest driver for my graphics driver, but haven't installed it yet. I wanted to turn the feature back so that I can be sure that updating the drivers will definitely be the step that's going to fix the issue. However, the problem hasn't come back, not even after a machine restart. I'm going to leave it (the registry) that way and install the driver update after posting this. Hopefully, we'll see no more of this issue.
It might be worth your while having a look at this web page. It gives a clear and concise explanation of the thumbnail cache situation on the latest version of Windows 10.
It also suggests TWO registry fixes are required to put an end to this constant and irritating rebuilding of the thumbnail cache.
I have just installed the second registry fix, although I have to say that the first alone put an end to my problems.
The first thing I tried was to update my video drivers. It made absolutely no difference.
I'm not sure why the thumbnail cache would affect what was shown in the dump, which looked like the Windows GDI component was stalling when it was asked to create bitmaps for drawing parts of the UI (not thumbnails).
I'm not sure either. It's also interesting why that tweaking the registry looked as if it had worked at first. It seems it has been a coincidence only.
On the other hand, I also don't get what kind of problem would the driver update solve that only manifests after restoring my Opus config. While I do have removed some toolbars and added a few other, I haven't done anything extraordinary. It's still drawing the same UI, isn't it?
I've tried the popular InSpectre tool which not only shows the status of Meltdown & Spectre mitigations on your system, but also provides the buttons to disable or re-enable the OS mitigations (I recommend to restart after toggling), so you can try if there's any difference.
In my limited testing (with mitigations disabled & after restart) so far it seems Opus folder-browsing while under heavy disk load is now back to pre-patch performance (snappy and unaffected). I'm not denying it could be a placebo effect, but it does seem better for now.
My guess is that this Windows update will fix the problem for you as well:
I didn't have a problem in Opus, but saw problems in another program, which are fixed after that update installed on my PC. The thread above is about a similar problem in Opus for a couple of people, which the Windows update also solved (for at least one so far).
