GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Sluggish response and long load times

I have begun to notice that the program seems to be really sluggish and load times can be long for new lister windows.
Anyone else encountered this with the newer releases?
Anything I can check or look at that might be causing the issue?
Regards
Ed

Is it only on particular folders, or types of folders? (e.g. network drives or USB drives, or HDDs which have spun down and gone to sleep.)

Or in folders with particular filetypes? (e.g. video files, exe files or archives can all see slowdowns due to external comopnents like video codecs and antivirus scanners in some situations.)

Was anything installed or updated around the time the slowdown started? It coule be due to a shell extenstion something has installed, for example.

Or were any settings changed around the same time, e.g. to fiter items or install new scripts, turn on new file display columns, or anything else you can think of?

Is the PC running low on memory?

Is anything in your configurating (e.g. toolbar buttons) pointing at a network drive that is unreachable? Or is a drive letter mapprd to such a drive?

I noticed this as well.
However I also recently added the ratings column in folder options to all my folders and just assumed that was the cause for the sluggish response.

Best thing to do is try removing it and see if it proves your theory. If not, my questions above have several other ideas to try.

Yep! I can be fast one minute doing the same function that it will take 10 minutes to do a second later. I can't quite explain what's wrong or why but it's definitely there one time and not the next. A delete can take forever, a load, a flat folder load, just opening a folder with 1 or 2 files or folders can take minutes or no time at all. Maybe some code got deprioritize within DO? Like it processes in a FIFO order instead of the most important first?

When it gets into one of these modes I often just try to close the program but even that can take a while through the Task Manager. I don't recall if I've ever tried the program close as opposed to the Task Manager and seen any difference.

My system is limited to networked or local I don't have any other types and some cloud synchs but I don't think that would affect DO as I'm not actively trying to access those folders through DO.

I haven't noticed anything in particular related to content.

It could be related to a shell extension but nothing new has been added although there have been updates to MS 10 itself which I had to back off in early September but this slowdown has been since I upgraded to 12.whatever. I was a late adopter of version 12 so there may be some answer in that. The other shell component that's been updated fairly regularly is File Menu Tools which allows you to change what appears in a context menu. Potplayer has been updated a couple of times but I don't recall anything special post-upgrade.

I haven't made any changes to configurations that I can recall.

Plenty of memory available.

No drives that should be inaccessible in fact the other day my server went offline and I didn't even notice until I went to fetch a file.

If it takes that long, the best thing to do is make some manually-generated process dumps while it's happening, then send them to us. We can usually use those to see which part of the code is being executed that is taking so long, and whether it's something in Opus or another component.

Here's how to make them (skip over the "Automatic crash dumps" section right at the top):

The current build of windows 10 has a performance spike bug so it could very well be that. It fits the description perfectly.

If you can, you might want to think of any recent changes to your system to track down the issue. Did you update windows, change your DOPUS configuration / toolbars, ect.

I don't recall making any changes to DO that I haven't had in prior versions. As for Windows 10 like I said, I had to remove the big update that came this September because it totally destroyed my computer. At some point that will get applied again. I think at the end of October actually but that update was removed and it was a problem before that.

This happens with some fair regularity so I might be able to get those dumps soon.

These files are automatically sent to Google Drive when I try to email them because of their size. A single file is 1.5gb using 7z. They will take hours to send.

I got back to my send and it looks like it terminated but let me know if you got it or not? I sent it to your crashdumps@gpsoft.com.au. It should include a link to GoogleDrive.

I haven't seen anything come in so far.

If the GoogleDrive link still works at your end, please re-send the link via email or a private message here.

Got one DMP so far. Saw your message about a second on the way. There's a lot going on at once at the time the DMP was made, most of it probably not related to the issue*, so I'll wait until I've seen the second one, as that should narrow it down.

(*Looks like a lister was being closed, while another thread was getting information about video files, while one command was moving or renaming files and two other commands were applying labels to files. Makes it hard to know which, if any, of those things to focus on.)

Based on the 2nd dump and "I had clicked on a file that resided on a network share to install it" comment in the email, I think the problem is your antivirus.

Windows Defender is quite bad these days at slowing processes down, especially if you go anywhere near large installer executables. It doesn't cache results of previous scans and blocks the entire program from continuing while it scans the file each time it is opened.

Try disabling Windows Defender and see if that helps.

You can also do some things to make Opus less likely to trigger it:

  • Under Preferences / Folder Tree / Contents, turn off Zip files and other archives.

  • (Alternatively to the above: Make sure Preferences / Zip & Other Archives / Zip Files: Hide from tree includes .exe so those are not shown in the tree, at least.)

  • Turn on Preferences / Folders / Folder Display / Show generic icons for for the type(s) of drives your installers are on. (Unfortunately, just reading the icon for a .exe file triggers antivirus to scan the entire thing as if you were going to execute it. This is a bug in Windows IMO; it opens the file the wrong way when reading icons, but it's outside of our control.)


The original and new dump also have something in common which is a thread that is getting information about video files in one of the visible folders. That could be involved, but it seems less likely. It shouldn't normally block anything, and the new dump definitely looks like the problem is with antivirus scanning an exe file.


Another thing to check is that the process priority (right-click dopus.exe in Task Manager's Details tab) is set to Normal. We recently found something that means it can be set to Below Normal in some situations (e.g. after installing an update, before rebooting). That could be slowing things down a little if the machine is under load. It's probably not causing the whole problem, but it's worth checking. (It'll be fixed in the next update, too.)