Likely I am the only one, but it strikes me that Opus became (very) slow over since a few days, or week or so.
Even when renaming just a few files (4-5) a pop-up shows up for some 5 seconds, before I can perform the actually rename (enter the old-new-boxes at the top)
Or just starting Opus from the taskbar, it takes somewhere between 15-20 seconds before showing up. Opus always starts in a default folder (\Downloads) and it used to be much faster.
Are there any settings that I should check out?
Or did something changed in v.13.13?
I was about to post a similar thread. Opus has been slow to launch since early February. I don't have any CPU hogs, and I haven't changed any other configurations. The only thing I can think of is it's trying to scan a volume and not getting the information quickly.
Is there anything anyone can think of that could be causing this?
No. It's the first time after a reboot, and I'm not trying to launch DO right away. I may work on email or something. It could be 30 minutes after the reboot.
I've actually exited out of DO. Counted to 10 and relaunched it and it is snappy, like 1 second.
I'm experiencing the exact same symptoms. Not quite sure when this started though. It's only on the first start of Dopus, after that it loads very quickly. I have a Process Monitor log from a few days ago but I can't see how to upload it. Dopus Logfile.zip (9.4 MB)
Realized I had to zip it first. Log attached
Sorry for not getting back on this. I should have, as topic starter.
Frankly, I let it rest and accepted Opus to be slower than before.
That said, I believe the rename panel shows up much faster now.
At first, when renaming (no matter whether 5 or 50 files) a small pop-up would first show up for a couple of seconds, then the actual list of file names to be renamed. The pop-up doesn't show anymore, the list is being displayed quickly now.
Because of similar (increasing) pain, I just did the above Google search and ended up in this thread.
Just wanted to chime in and add my own data point. Recently, it takes around ~10 seconds for Dopus to simply draw its own user interface on my Dell XPS 17 workstation laptop (i7, 24GB RAM).
To be precise about the behavior: It is not an initial timeout or freeze followed by the window instantly snapping into place. I can literally watch Dopus paint its UI button by button, element by element, for about 10 seconds until the window is fully rendered. This not only happens during a first start of Dopus, but also when I simply open a new lister from within Dopus.
I spent quite some time trying to hunt this down on my end to make sure it's not just a messed-up local config. I tried Dopus Safe Mode, disabled all 3rd party shell extensions via Sysinternals Autoruns, disconnected all network drives, unplugged the Thunderbolt dock, disabled Dell's audio hooks, and even dropped the external 4K monitors down to 1080p. I also forced the app to run on the Intel iGPU, and then the Nvidia dGPU. Unfortunately, the slow-motion rendering remained exactly the same.
As a final sanity check to ensure my Windows installation wasn't completely broken, I ran a different (portable) file manager. Even with a similarly dense multi-pane layout and plenty of toolbars, it rendered its UI and long file lists instantly, so the OS itself seems perfectly capable of drawing complex file manager UIs quickly.
The situation feels a bit like Dopus is somehow being forced into a severely bottlenecked software-rendering fallback.
Just leaving this here in case anyone else is experiencing this exact "slow-motion painting" effect recently, or if anyone has figured out a quirk with modern setups.
For the avoidance of doubt, this sort of thing is absolutely not normal.
If you want to make a process snapshot and send it to us we can tell you what third-party DLLs are loaded in the process (on the assumption that this is being caused by something interfering with the process, notwithstanding the things you've tried disabling already).
