High DOpus CPU usage during non-DOpus operations

Hi chrisp,

I've experienced similar difficulties with Directory Opus - with a disproportionate amount of time spent in the background DOpus process vis-a-vis time spent in other file-intensive applications. I've written about some of my experiences in this thread here (although not to the level of detail that you have explored!):

The solution that I've found, for the meantime, is that I always run Dopus in "no-external-change-notify" mode, and I use an AHK script which automatically sends a "Refresh All" command to Dopus whenever I move a lister to the foreground. (Yes, DOpus is that good - unparalleled in so many ways - that I stick with Dopus despite this workaround!) I included the source for the AHK script in my post referenced above.

Overall, I find this to be an excellent workaround. When Dopus is in the background, it doesn't interfere and doesn't clock any context switches. And when I do bring it to the foreground, it's up-to-date within milliseconds.

The one problem with this setup is that the "Refresh All" command also resets a few other things: it resets the file selection; the file filter; and the GO command line (that is, any half-typed commands are closed up).

I've thus asked the developers whether they could add a command to perform a "Soft Refresh": a command which would cause Opus to reread the list of files within the directory, but which would (file-list permitting) still leave intact the selection, the filter, and the Go bar.

I believe that if a Soft Refresh were available, then the ideal way of running Dopus really would be the "no-external-change-notify" mode, with automatic Soft Refreshes.

In any case, chrisp, I found your messages here very informative and insightful (and I found your spelunking stamina to be inspirational!) Thanks!