When I have one instance of Directory Opus busy doing work like deleting a folder with hundreds of thousands of files or unzipping a very large zip and I launch one or more instances, those instances become extremely slow or unresponsive. One is showing an hour glass all the the time for example. The computer is not that busy because I can switch to any other app and work in it.
Is this normal behavior? And when the busy instance is done working, all the instances seem to be busy doing something. The hour glass keeps switching between hourglass and the mouse cursor for many minutes then all the instances get frozen and I get impatient and kill all the DO processes. It seems the file structure has changed so much, DO is refreshing itself or something and it's taking forever. Just my guess.
I also noticed even though I open several instances, I only see a single dopus.exe and dopust.exe running which suggests that these instances don't seem to be independent of each other and if one goes haywire, the others are affected.
Try disabling your antivirus scanner. Sometimes those can freeze the whole process when scanning files read or written by just one thread.
Script add-ins could also do this if they are not behaving. Try disabling any you have installed.
Shell extensions can also cause problems. The troubleshooting section of the FAQs have some guides about tracking them down, as well as other possible causes of slowdowns.
But these slowdowns happen with the extra instances only while the first one is busy working. Those instances don't seem to be independent new processes in Windows. For example, in Chrome whenever you open a new tab, a new Windows process is launched and all the tabs are independent. If one is slow or crashed, it doesn't affect the other processes. Your model is not the same. All the instances seems to be running in the same process. If one instance is taking over, the other instances suffer. Correct me if I am wrong.
Our tabs are in-process, not separate processes like Chrome. But doesn't change anything I said/suggested.
(Chrome's tabs can also still run slow if a common element they need to talk to becomes slow/busy for some reason, such as the main UI process. Chrome's design is about security more than anything else, since content from the web is potentially hostile. It's not about performance.)
Threads don't "take over" each other normally. They're given a share of CPU time the same as separate processes. But if something one thread is doing is blocking the others from being able to run in parallel, then that can cause a problem. (That can also happen with separate processes.)
The things I suggested looking at can all do that, which is why I suggested them.
Your instances are running in the same process. Probably that's the issue. I can unzip that huge zip in File Explorer and launch another File Explorer and that instance runs and is responsive, unlike Directory Opus. The File Explorer instances are separate Windows processes. Most of your suggestions are not practical. I am not going to disable my antivirus software just so that another DO instance can work and expose my machine to risks. Plus the shell extensions I have work fine inside File Explorer. And it's time consuming to figure out which one is causing an issue if actually if one does and the ones I have are needed. I am not going to remove or disable them.
Anyway, not a big problem. I will just File Explorer when needed.
Threads running in the same process still run in parallel. It literally makes no difference to performance, unless they are bottlenecking on a common resource, which can happen between processes as well (or unless something outside of our code is pausing the whole process, which shouldn't happen but isn't unheard of).
Threads vs processes is a matter of shared memory, and not much else. It's generally more efficient to use threads than separate processes.
The suggestions I made are to find the cause of the problem. I am not saying you should turn off your antivirus forever, only try turning it off temporarily to see if it is involved. If it is, we can investigate that further. If it isn't, we can rule that out and focus on the various other possibilities. In either case, you can turn it back on after doing the test.
What you're seeing is not normal, and will be caused by something. That something is not the fact that the threads are in the same process instead of separate processes. But it's difficult to guess what it is, and you will probably need to try things to work it out.
You could also create some manually-generated dumps while the slow-down is happening, which we can look at to see where in the code (ours or someone else's DLL that's injected into our process) the different threads are executing, to see if that tells us why things are slow. Instructions on that are here: Crash dumps for bug reports