DOpus stops responding while dealing with huge number of files

I'm using npm (package manager) - it creates folder named "node_module" which contains huge number of files (like 30k of files). Sometimes I need to delete this folder and recreate all packages.

The problem is DOpus stops responding - sometimes even for several minutes - after deleting such folder (I'm doing this using DOpus delete function). Is there anything I can do to prevent this from happening, apart from closing DOpus? Or maybe you guys can look into this issue and try to find a solution?

I have just one open lister with this folder.

Several things you can try here:

Turning no_external_change_notify to true solves the problem and the performance is significantly better. But keeping it on doesn't look like a good idea. Knowing this, can you provide any additional tips?

(Edit: of course I tried turning off Process file changes in background tabs, but it didn't help)

They're already in the post I linked. :slight_smile:

Process file changes in background tabs - didn't help
collection_change_delay - didn't help
no_external_change_notify - this helped but it's probably not a good idea to keep this options on
notify_debug and shellchange_debug are off
I tried to set notify_max_time to 200 and notify_max_items to 100 but no change.

DOpus is not responding when deleting node_modules folder (30k of files) and very frequently is still hung when the deletion process completes (I can't bring DOpus window to top by clicking on taskbar and clicking on windows that are in the front doesn't do anything)

Closing folder tree did help a lot. :slight_smile: Is there any option for DOpus to refresh folder tree less frequently? I usually have more than one lister open, even related to one project, and don't want to manage many DOpus windows when dealing with node_modules.

A ProcMon log and some manually generated dumps while the slowdown is happening may let us explain/understand the cause, and perhaps see if there's an opportunity to make Opus handle this better (e.g. by dumping notifications if they reach excessive numbers, which I think we already do, but may not do in all places we can, perhaps).

Hello again,
I've sent you my logs some time ago. Did you have an occasion to look into the matter since then?

The dumps all show it's the folder tree which is the bottle neck, trying to keep up with the change events.

It may be compounded by the huge number of events being for folders below your Documents folder, which can appear in multiple places in the tree, including virtual paths which are a lot slower to process.

Moving the folder out of Documents might help, although I can't guarantee it. Turning off the tree while doing this kind of thing would be best if it's causing problems.

Haven't had a chance to look at the code yet to see if there are (more) places we can make it start dropping events if there's too much of a flood. That's a longer term thing.

In the process monitor logs, there's a long stretch of time where almost nothing happens on the machine except for the Microsoft antivirus reading from temp files, which might also be significant (or not).

There are also other processes that are looking at change events and/or the same files, which may mean contention issues, fighting over resources. (Node.exe and Jetbrains)

IntelliJ is very slow only while npm is in progress of downloading dependencies and is back to normal several seconds after npm finishes working - and I'm fine with that.

DOpus on the other hand, keeps freezing long time after npm finishes, e.g. a window is not responding at all for several minutes or the controls in DOpus window seems to react to hover and clicking but if I double-click a folder [edit: I mean a folder in DOpus lister], nothing happens (or happens after several dozens of seconds).

I'll try moving my workspace somewhere else, though.