CPU Usage In Idle CAD Systems

One particular anonymous comment to my last post title “3D Graphics Performance Comparison” peaked my interest. This is what it said:

“I have a really annoying problem regarding to performance in SolidWorks, it’s CPU usage. While moving the mouse over an empty part in SolidWorks I get 50% CPU usage on a dualcore machine. ProE only reaches 10~12%.”

I found it odd that SolidWorks would use half my CPU cycles, that too in what I believe is its idling state, just to figure out what it should do with a mouse movement that I just made. This meant that if I had some other application doing some heavy work and I switched to SolidWorks just to look at something or navigate around a model, SolidWorks would eat up a significant chunk of the CPU cycles and leave the other application waiting. I thought when applications are in their idling state, they basically sit tight until you do something significant with them. I didn’t know that moving the mouse in a 3D graphics window was as significant as the reader was suggesting.

So I decided to dig a little deeper. I fired up a bunch of CAD systems installed on my computer simultaneously and created new empty documents in each of them. I started the Task Manager and observed the CPU usage as I switched from one CAD system to another and moved my mouse in their empty 3D graphics windows. Here is a video I recorded while I did that. Notice the extent to which the CPU percentage increases for each CAD system.

So the reader was right. On my computer the CPU percentage for xtop.exe (Pro/ENGINEER) rose up to 7%. Whereas for sldworks.exe (SolidWorks) it jumped up to 33%. And I wasn’t really doing anything in these programs, or so I thought. Alibre Design, Inventor, MoI and VX were in the Pro/ENGINEER category and all were under 15%. SolidWorks, SpaceClaim, KeyCreator, CoCreate Modeling and KOMPAS-3D were under 35%. The worst was Solid Edge which hit 50%. I understand that the readings of Task Manager are spaced one second apart. So these numbers are actually samples and not the actual maximum values. But I’m pretty sure that they give a good indication of exactly what is happening.

It is important to note that my computer was busy doing other stuff while I was moving my mouse in these CAD systems. I was busy downloading a bunch of files among other things. And of course, I was recording the video itself which was a continuous process. So the CPU definitely had other things to devote its time to. It appears that these CAD systems were using a significant chunk of my CPU cycles, in one instance, precious half of them.

Now I happen to know a thing or two about 3D graphics. But my specialty is something else. So I am looking for someone to explain to me and my readers exactly what these numbers means. Do these numbers, in some way, signify the efficiency of the CAD system or the lack thereof? Or are they insignificant and must be ignored? If you need to explain this is greater detail and would like to write an article on this blog about the subject, click this link.

I hope someone has a good explanation as to why some CAD systems take up to half my CPU cycles when I am doing absolutely nothing worthwhile in them.

  • Amit

    I had observed this behavior in some simple graphics (OpengL) applications I wrote while in college. OpenGL being event-based, a mouse movement is captured and the display callback is executed causing a refresh or redraw of your display. In these cases, the CPU usage will show a jump. A hack is to use the sleep() function which interrupts/holds the executing thread for a short interval. This will reduce the CPU usage in some instances BUT can result in the application “hanging”. A more correct solution would be to calculate time interval between 2 successive events (mouse movements in this case) and if the time interval is less than the reciprocal of the monitor refresh rate, do not refresh or redraw. This also resulted in reduced CPU usage. This being said, I dunno exactly how or if CAD systems address this issue.

  • Very interesting. Thanks for your input.

  • Michael Gibson

    > Do these numbers, in some way, signify the efficiency
    > of the CAD system or the lack thereof?

    Possibly… It's certainly not a particularly good sign to have a lot of CPU chewed up when nothing is going on.

    Are you certain that actually nothing is happening though?

    For example in MoI when you move the mouse around the x,y,z coordinates under the mouse are displayed in the bottom toolbar – that's what is chewing up a little bit of CPU for MoI's particular case.

    Take a close look at the GUI for the apps that are chewing up more cycles, is there anything similar to that like a coordinate value being updated when you move the mouse?

    If so then it might indicate that the GUI is being redrawn in a non-optimal way, like either too much of the window is being repainted instead of just the box around the coordinate values, or possibly in a worst case maybe a whole UI layout process is being triggered due to new values in the UI.

  • Michael,

    In an event driven system something's always going on. However, one would expect that the window refresh is done in an optimal way, like you suggested. In MoI's case, yes, the toolbar was being redrawn, but in other cases there was nothing underneath the mouse. Even if coordinates are being refreshed, that should be simple number transformations. I mean, take xy mouse coordinates, pass them through the view transformation matrix and you should get the world coordinates which you put on the status bar or wherever. The graphics pipeline should not be troubled by this. I know that this more of a simplistic way of looking at it. But I think you get my point.

  • Patrick Hughes

    If you are inclined to pursue this further you might obtain more meaningful data for each program using Process Explorer and/or Process Monitor.

    http://technet.microsoft.com/en-us/sysinternals

    I've always wondered why so many software developers set the priority to a minimum of “Normal” In the case of the cad time logging program I've developed it is set to “Low”.

  • Deelipreader

    there should be some bugs in solidworks, closing toolbars and the ribbon by pressing the F10 key, saves me up to 20% CPU load.

  • Michael Gibson

    > I mean, take xy mouse coordinates, pass
    > them through the view transformation matrix
    > and you should get the world coordinates

    Yeah this part is trivial and should not chew much CPU at all.

    > which you put on the status bar or wherever.

    Ah, well this simple “put it on the status bar” is the part that has the potential to be surprising complex, especially if some new fancy layout-based system like WPF is being used for the UI. It is fairly easy for some systems like that to end up doing a larger re-layout (which then causes a larger repaint) of surrounding UI when something changes.

    This stuff that I'm referring to would be happening in the surrounding UI part of the application (like its toolbars and buttons and stuff like that), not actually anything to do with the 3D display pipeline.

    That's just a guess though.

  • Deelipreader

    there is a set of tools (WPFPerf Performance Profiling Tools ) for developers which allows to pinpoint the exact CPU usage of each element of the programs which use windows presentation foundation. deelip, perhaps you can use it to see where the problem is.

    here's a picture of the tool:
    http://windowsclient.net/SiteFiles/1000/wpf/per

    and a page containing the download link:
    http://blogs.msdn.com/b/jgoldb/archive/2010/05/

    thanks for devoting an entire blog post to this problem.

  • Thanks for the links. Shall do this when I get the time.

  • Michael Gibson

    Well, that does seem to indicate that it is likely an excessive toolbar/ribbon redraw issue as I was mentioning above.

    The worst kind of thing is when something actually recalculates the entire UI layout and not just a repaint, because layout calculations will take a fair amount of CPU by themselves and layout will tend to make more elements want to repaint themselves as well so the paint area becomes larger too.

    This kind of thing can get masked when all the developers and testers and most users are running on brand new high powered machines, and then when someone comes along with a slower machine it can't deal with it as well.

  • Gmatelich

    In most of these cases I believe there is probably a lot of polling going on, looking for whether the mouse is over a face, an intersection, or some other key point. It doesn't make a lot of sense in an empty part, but I assume that isn't part of the equation – just cursor is here, is anything under it, cursor is here, is anything under it, cursor is here, is anything under it. . .

  • Rob

    The most recent osted by Gmatelich is the most likely situation. CAD systems typically do 'mouse-over' selection in a continual fashion, and frequently by default. This means the gfx engine is continually doing selection/hit-testing everytime the mouse moves, to figure out what is getting selected. This is a CPU-side process (unless the gfx engine is doing shader-based image-buffer 'visual' selection, which is fairly sophisticated and unlikely), and can be intensive depending on the complexity of the scene, the selection filters, the lack of optimization in the selection algorithm, etc…

    Now, if selection-testing is completely turned off (if the Options dialogs allow you do set that and you can be certain that no mouse-over selection processing is happening) then yeah, something else is going on. No, it should not be the gfx system redrawing anything, nor the GUI getting repainted, though I guess the former is possible if there are some major design flaws in the CAD software. Beyond that, it's just a guess…

    Rob