GP SoftwareTwitter
Opus FAQsManualCommandsObjects

Performance Drain After Upgrading To 12.9.x


#1

Hello!

I'm having a rather weird problem with Directory Opus since upgrading to 12.9 (and subsequently the 12.9.2 beta). When DO is open, the performance on my system drags when dealing with file moves, copies, renames, etc.; even clicking from one lister panel to the other to change the highlighted panel take 1 to 2 seconds to complete and yesterday when I tried to search for a file in a number of folders, I literally had to close DO because the operation was taking so long (to give an idea of what was being searched through: I have about five hundred files spaced out across 27 folders in a given directory; historically, the search should have taken one to two minutes tops but I closed DO at the twenty minute mark).

I wasn't experiencing these performance hits with DO 12.7 but since upgrading to 12.9, performance has been so bad that I've literally had to stop using DO and switch to Total Commander (a solution that's not really a solution, since TC is not DO). And the performance problems are only related to DO; Explorer works fine as does TC with DO closed. With DO open, everything is a bit jittery including games and window rendering but when DO is closed, everything sings on my machine.

Any ideas what might be causing this issue? (I know the answer will more likely be 'not without further information' but I thought I'd ask.)

If not, what can I provide that will help to diagnose and resolve the issue? Likewise, where can I download 12.7 to reinstall to make sure that it really is 12.9 causing the problem and not some weird update that Microsoft pushed to my computer (I don't think it has anything to do with updates (or other software since DO was the last update I made) but you never know with Microsoft).

Thanks,
D

My Rig Stats:

Windows 10 Professional Version 1803
MSI X99A SLI Krait Edition Mainboard
128 GB GSkill Rip.Jaws RAM
Intel Core i7-5820 6-Core CPU at 3.3 GHz
EVGA GeForce 1080 Graphics with 12GB onboard RAM
135TB Storage Array (DriveBender pool consisting of 2 Lenovo DAS Arrays and 10 external hard drives)
Samsung EVO 1TB SSD System Drive
Western Digital Black 1TB Installation Drive
Kingston 250GB SSD Transient Drive


#2

Opus 12.7: http://leo.dopus.com/temp/DOpusInstall_12.7.exe
Opus 12.8: http://leo.dopus.com/temp/DOpusInstall_12.8.exe

Try each version to test the theory that the performance difference is due to 12.9 and not something outside the version change.

But please only use them temporarily. If we don't get to the bottom of what's causing the problem, you'll be stuck on an old version forever, and other people may also run into the same problem.

If you do find the problem goes away with the older versions, please check that reinstalling 12.9 brings it back again. It could be that something did not install properly, or happening during the reboots. (Do reboot after each version is installed, if prompted, as otherwise not all the components will be fully updated.)

If the problem is only there in 12.9 or 12.8, let us know which version it begins with so we can narrow down where to search.

If the problem is still there when you go back to 12.7, the next thing I would try is reverting to the default configuration:

  • Use Settings > Backup & Restore to save your existing configuration, so you can go back to it after testing.

  • Uninstall Opus via the usual Windows Control Panel. This will wipe the configuration.

  • Reboot if prompted at the end of the uninstall.

  • Install Opus again (no further reboot should be required).

If the problem is gone, try restoring the config backup to see if the problem comes back.

If it does, it will usually be because something in the config is pointing at a network drive which is no longer accessible (e.g. for toolbar button icons, or shortcuts on the toolbar, or potentially in the Favorites branch).

You can send the config backup to crashdumps@gpsoft.com.au if it seems to be config related and you'd like us to look at it.

Process Monitor logs of what is happening during the slow-down can also be very useful: Process Monitor instructions

Another thing you can do is, during the slow-downs, generate some process dumps and send them to us. That may allow us to see what is happening.


#3

Hi Leo,

I appreciate you getting back to me in short order.

I'll follow these instructions and let you know what I find but it may take a couple days since I've got work and this is on my personal machine but I WILL get back with answers to your questions and with the requested logs if necessary.

Thanks,
D


#4

Hi Leo,

I was able to do some testing and it seems like you were spot on with the problem being related to my configuration somehow.

Here's what I was able to accomplish:

To install 12.7, I had to uninstall 12.9.2 which effectively cleaned out the configuration. I popped open DO and backed up my configuration prior to uninstalling 12.9.2, as you instructed, then uninstalled, rebooted and reinstalled but I started with version 12.8 instead of 12.7 because I wanted to see if I ran into the same problem with that version (never really got back to 12.7 in fact).

Upon initial installation everything was running great (at this point I was suspecting something with 12.9.x): windows were opening with prior speed and file operations were running great, etc; there was no degradation in performance at all even after multiple file operations. So I was going to uninstall and install 12.7 to see if the same happened there but I decided to restore the configuration to see if that would have any affect (again as you instructed) and, low and behold, it did: After the restore, things worked great for about ten minutes until I started working with files and then the performance started dropping and eventually slowed to a crawl again. Once the performance degradation started, even restarting DO didn't fix it: I restarted DO three times (exited DO and killed the DO helper application) but no-go; when I fired DO up again performance was still at a crawl. Before I uninstalled and reinstalled again, I rebooted to see if that would fix the performance issue and it did temporarily but once I started working files again, performance started degrading again. I'm not sure why killing the program doesn't fix the problem and a reboot does (memory issue maybe?) because when DO is closed, the tangential effects (slow window renders in other applications, file selects, etc) clears up but when the program restarts, the tangential effects are clear with DO still being sluggish until I start working with files and things degrade outside the application again.

After rebooting, I uninstalled v12.8 and reinstalled it to perform my tests again to make sure that I hadn't done something to mess things up. Tests went exactly as before: before I restored the backed up configuration, things were working great, restored the backed up config and things started crawling again.

At this point, I uninstalled 12.8 and installed 12.9 (not the beta, the GA release). Once 12.9 was installed, I repeated my tests and got very similar results. I say similar because there is still a performance drop on .9 without the restored backup although that seems to be related to EaseUS Todo Backup (when backup jobs are running is when I see the hit) but it's acceptable and I expect some performance expense with large file copies from the DriveBender pool since amalgamating 36 separate hard drives into a single virtual drive comes with overhead (and truly, that hit may have been there with .8 as well because I didn't test backups with that version of the software installed). That being said, once I restored the backup to 12.9, performance immediately dropped into the unacceptable range: switching lister panels was again taking 1 to 2 second and highlighting a stream of files was taking ten and required multiple lasso swipes which would sometimes create aberrant shortcuts, etc. Once I uninstalled and reinstalled without the restore, things seem to be back to normal; been using DO for the last eighteen hours with no hits in performance aside from the backup job degradation.

So long story short (too late), it seems there was a problem with my previous configuration although I do not know what as I have no network drives to speak of and to be honest, restoring the backup config didn't change anything on the surface: everything looks exactly like the default listers save for column placement. That's not to say it isn't something under the hood, but truly, there was very little visually that changed from the default config to the restored config. I'm going to email the backup of my config file, to the address you provided above, for analysis. I really would like to know what the cause of the issue is and hopefully it'll be able to help someone else who may run into a similar problem.

Thank you again for the guidance and for getting back to me in such short order.

D


#5

I had a look at the configuration you sent (many thanks!) and nothing there looks out of the ordinary, except maybe the Find Results collections -- if they are pointing to a drive that doesn't exist, or maybe triggering antivirus or something, then it could slow things down, since Opus checks the files still exist and if their sizes have changed when it starts up.

Other than that, everything looks like a default config, at least that I can think to look at. The toolbars are all default, and there are no scripts or favorites, which would be where I would normally look.

If the problem does come back, there are a couple of other things we can do to try and track down where it's coming from (mentioned briefly above, but here again so you don't have to dig through the old posts when/if the problem comes back):

  • A process monitor log can show us which files and parts of the registry are being read, as well was which component is reading them. If a log is created while the problem is happening, it often reveals the cause, or the direction to look:

    Process Monitor instructions

  • Making some manually-generated process dumps while the problem is happening can also reveal which code is active at the time of the problem, although it can be a bit hit & miss as we only get a snapshot of where things are at the time each dump is created:

    Crash dumps for bug reports