You can reduce overheads of change processing with these settings:
-
Preferences / Folder Tabs / Options / Process file changes in background tabs -- Turn that off to avoid inactive tabs processing events. Instead, they'll flag that they are 'dirty' and re-read the directory if needed the next time they become active.
-
Preferences / Miscellaneous / Advanced [Troubleshooting]: collection_change_delay -- Controls how often changes are fed to collections. (Deleting any old, unwanted collections can also reduce overheads in some situations.)
-
no_external_change_notify in the same place can turn off processing of external events entirely. We don't recommend keeping things like that, but it can be useful to verify that that's where the overheads are really coming from, and that there isn't another issue hiding somewhere.
-
Still in the same place, make sure notify_debug and shellchange_debug are both off, unless you're actively debugging an issue with them. The extra debug output can slow things down.
-
Still in the same place, notify_max_time and notify_max_items can be used to control how often changes are dispatched to listers/tabs, and how big the batches are.
-
If the folder tree is open, it has to listen to change events for just about everything, which increases overheads. Closing the folder tree (in all open windows) can reduce overheads.
-
Aside from that, it should only be drives or folders which are open that are monitored. We generally monitor the whole drive if it's a local drive and something is pointing at a folder below it, but there are cases where it's done on a folder by folder basis. If any monitoring is happening for a drive or folder+children then it will cause some overheads, even if the files turn out to not be in a folder that is currently displayed, since there's an overhead in looking at the paths and working out if anything is displaying them. Most of the overhead comes from the file displays processing things, however, which the settings above can help with.
Having said that, SYSFER.DLL looks like it is part of Symantec's firewall or antivirus software, so seeing that many nested function calls within that DLL in the callstack for the high-CPU thread suggests it may be causing the issue, perhaps by scanning files unnecessarily, which could mean the CPU usage you're seeing isn't really caused by Opus. But it could also be a red herring.