I've been putting up with the occasional freeze when I switch back to DO and it just hangs for 30-40 seconds before becoming active, but lately its become worse.
Now every time I change form another app back to DO, it hangs and I have to wait 30-40 seconds before it frees up.
Can I turn on any logs to try and track this issue down?
Right-click an empty space on the taskbar and open Task Manager.
On the Details tab, find dopus.exe and highlight it so you can quickly find it again in a moment.
Now go back to Opus and see if it starts to hang. If it does, quickly go back to Task Manager, right-click Opus and choose Create dump file. That should create a dump of the process and tell you where it has saved it.
It might make sense to do this a few more times, to make sure the dump gets created while it is still hung, and in case it's not always during the same operation.
If you then zip and email the dump files to leo@gpsoft.com.au I can take a look.
My guess is there is either a script running in reaction to the window becoming active, and the script is taking a very long time, or there's some kind of interaction with a 3rd party tool or component. The dumps should let us see which, or if it's something else.
I seem to have noticed (DO11) that if you do some heavy file operations (processing a lot of files) in other programs Opus may seem to hang for a while as if it needs to adapt to or digest the changes.
BTW, Windows memory management may play a role in this too. If you don't use an open program for a while, you may notice that it takes a while (sometimes up to a minute) before it responds, if you try to access it, and you can see from the drive LED that a lot of disk activity is going on. This is, AFAIK, Windows memory managent that has transfered the RAM the program uses temporarily to the swap file so it has to read it back again when you start to use the program again, and this may take some time, depending on how fast your system and swap disk etc. are. Whether it affects Opus I don't know (maybe you can prevent it with some programming?), but it does affect many other programs.
You can set Preferences / Miscellaneous / Advanced: no_external_change_notify = True to test that theory.
Closing unused windows & tabs will reduce the amount of work needed. Closing the folder tree, if you are not using it, also helps, since it means Opus only has to care about the folders it is actually showing.
It's unusual for there to be so much filesystem activity that this would happen, but there have been some cases of it with unusual processes constnatly creating files (into hundreds of thousands) non-stop for hours on systems under heavy load, which will eventually make the change queue start to back-up.
We've made a change that will go in 12.0.7 which we hope will improve things. It addresses what's running slowly in your dump files, but it's always possible there are more places which hit similar problems.
To help in the meantime, it looks like one of the folder tabs you have open is pointing to a slow or inaccessible location, which is what's triggering the long delays. Finding and closing that tab may fix things for you if you want to look for a solution before 12.0.7 is ready to try (or if you don't want to try the Opus 12 public betas at all).
Turning off "Preferences / Folder Tree / Appearance / Highlight path to all currently open tabs", or turning off highlights entirely with the option above that, may also help, if you can't find the tab (or have to wait too long to be able to close the tab). Closing the folder tree should also help but is more drastic.
The underlying issue is that just checking of a path exists can take up to 30 seconds if it's on an inaccessible network share (or similar), but is usually instant otherwise. The fix we're going to try in 12.0.7 moves some of those checks to a background thread so they will still take a long time but won't block other things while they're happening.
I had suddenly problems with Directory Opus 12.3 hanging frequently for approximately 10 seconds when switching back from another application to the Directory Opus window.
I indeed had a folder tab pointing to the insides of a tar-archive on a disconnected network drive. After closing this folder tab performance was back to normal.