I just noticed the varying degree of CPU usage of Dopus when a lister is opened on a folder which another process is updating the files in. I've seen it as high as 34% after a brief observation period. (I'm running Windows deployment tools like DISM, and had a lister opened on C:\Windows\Logs\DISM which contains only dism.log). I'm just wondering if Dopus code can be optimized a bit in those scenarios.
If you're asking Opus, plus any involved shell extensions (and anti-virus etc.), to process millions of changes to a large folder which it is displaying, that's going to cost some CPU. No way around it.
If it's using a lot of CPU for a long time then that isn't normal. It could happen with pathological cases (e.g. a single folder with 100,000 files all being modified constantly), or with problems due to shell extensions or antivirus (they are involved with processing and displaying modified files as well), or using things like Flat View (massively complicates working out which item on the screen to update).
C:\Windows\Logs\DISM on my system is a folder with just one file in it, so if there is high CPU usage there I would expect the problem to be something external to Opus which is reading the whole file every time it is refreshed (e.g. when Opus asks for the file's icon, or certain columns, external code can get involved). Or it could result from the file being opened and closed thousands of times a second for a long time, but that would be unusual for a log file (and very slow for whatever was writing to the log as well as anything aiming to display the log's current state).
I was watching the CPU usage of Opus in the process list of Task Manager when the Dism folder with the one file in it was opened in a lister while Dism was servicing a Windows offline image (applying cumulative update to the image): that's where I observed Opus going to 34% CPU at times. When I closed the lister, Opus went down to zero (or so) CPU usage.
That's unusual, but could be due to many things, only some of which would be Opus.
If you want to look into it, use Process Monitor to see what is being done in the folder, and Process Explorer to see which thread within dopus.exe is using a lot of CPU, and then click the Stack button to see which DLLs are involved. If it points to non-Windows DLLs outside of Opus, it's probably them.
Both tools require technical knowledge and time, so if it's not causing a problem and just a curiosity it may not be worth it to you, but the tools are there to investigate it further if it is.
I was just trying to give your development team a "heads up" on a potential issue you may have not noticed. Perhaps your development team could use the tools you mentioned to investigate the scenario, and potentially "refactor" the code if possible.
It could be any of these things:
- a process (or processes) on your system writing to the log file in a highly unusual way
- a shell extension installed on your system reacting in an unusual way when asked to inspect the file
- antivirus on your system doing the same
- something specific to your Opus configuration
- something the code in Opus itself is handling poorly
- something else I haven't thought of.
Given the range of possible causes, and that it isn't something that happens normally or on our own machines, it's not something we can go into the Opus code and magically refactor without knowing more.
It may not even be something in the Opus code that needs changing at all.
At this stage, it could only be investigated on the machine it is happening on, which only you have. If you ship your computer to us we can investigate it, but otherwise the tools are there if you're feeling technical and want to to investigate.
There are other things that can be done to diagnose what's going on as well, but they're similarly technical and can only be done on your machine, and would only really make sense after trying the two things I've already suggested. Up to you if you want to try them, but there's not much we can do at our end at this stage of knowledge.
It's not causing any problems for me, but just noticing that would make me curious about it if it was my product. I'm a developer, so I'd try to design that behavior out of the program if possible. I'd go looking at the code that monitors directories for changes, and the design of that code, and build a test case for it. Someone who knows the source code that handles that could address the matter best. I'm again going to install the latest Windows build and I'll be using the deployment tools some more, so I'll take another peek at the CPU usage of Opus in the same scenario then, but I really don't expect a different result. The process monitor shows Opus using a significant amount of CPU when it "isn't doing anything" (just a lister opened on a folder with one file in it that is being written to). I think the question to ask, is if Opus can monitor folders more efficiently and use a minimum of CPU when it's not actually processing files and folders.
The code is immensely complex so we can't "just look at it".
The problem may not be in our code. It may be something else on your system that is mixing with our code (antivirus, shell extensions, etc).
There's no magic fix here. The problem needs to be understood first.
If you're a technical person and a developer, loading up Process Monitor and Process Explorer and seeing which file operations are happening, and which DLLs are involved with the CPU usage, is quick and easy. If you want to help us, please do that. The information could lead somewhere useful.
We might be able to see something if you send some dumps as follows (which will be similar to the Process Explorer / stack part, although not as good as using Process Explorer on the machine where it is happening):
While it's happening, please go to Task Manager, then the Details tab, right-click dopus.exe and select Create Dump File.
Do that 4 or 5 times, and it should create something like:
C:\Users\<username>\AppData\Local\Temp\dopus.DMPC:\Users\<username>\AppData\Local\Temp\dopus (2).DMPC:\Users\<username>\AppData\Local\Temp\dopus (3).DMPC:\Users\<username>\AppData\Local\Temp\dopus (4).DMPC:\Users\<username>\AppData\Local\Temp\dopus (5).DMP
Please zip those up and email them to crashdumps@gpsoft.com.au
I'll keep an eye on it, but I can't get into investigating it for you right now, as I have my own stuff to work on, and it is not affecting my use of Opus. I just wanted to make a note of my observation.
1 Like
A stack dump would tell us if you can manage to do one and send it to us.