Author Topic: Objective tests, show csrss.exe hogging the CPU when using dimensions  (Read 6634 times)

corlett

  • Jr. Member
  • **
  • Posts: 95
Objective tests, show csrss.exe hogging the CPU when using dimensions

I found V20 to be slower than my V16, so I have conducted some tests to find out why.

The main observation is that a process called csrss.exe uses a lot of the processor.  By experiment I have correlated the saturation of the processor and what it is associated with.

My first observation showed that in a drawing containing only dimensions slows dramatically and csrss.exe is the main process hogging the CPU.  Ordinary drawing lines do not slow to anything like the same degree.

More rigorous tests.
I used WindowsTaskManager to display CPU usage and Kernel times, with UpDateSpeed set to high and I look at the process list in order of CPU usage. (I use this method to search for virus activity)
My objective test is to add entities to a drawing then “select, select, select” and see if the WindowsTaskManager graph showed a flat top (ie. 100% CPU), I called this CPUSaturation.

I added a simple linear dimensions and a simple diameter dimensions.
I added an ordinary entity: a box drawn with “]”
I noted how many entities were required to reach CPUSaturation, after 3 selection clicks.

Only 120 Simple linear dimensions to reach CPUSaturation (840 points)
960 Diameter dimensions required to reach CPUSaturation  (4800 points)
Box only entities, required 100,000 entities (700000 points) before CPUSaturation.
Clearly something is amiss with dimensions.
I also noted that in the dimension CPUSaturation conditions the Kernal was also running at 100% but for just Box entities, CPUSaturation was reached with the Kernel running at 20%.


I then drew the simple dimension but with DrawAsText and noted that many thousands were required before saturation was reached. So it’s defiantly something to do with the way DesignCAD handles dimension entities.

I used V16 and found that it could handle many thousands of dimensions with out slowing down. Csrss.exe shows up in the process list but does not hog the CPU; also the Kernel does not saturate when the CPU does.

I reverted to using V18 and found that it too slowed down when very few (120) dimensions were added to an otherwise clean drawing.

Conclusion
I respectfully offer the observation that between V16 and V18 an inefficiency in the code has lead to an objective speed reduction of 100x slower when manipulating dimensions.

Clive



PS
Csrss.exe
The Microsoft Client Server Runtime Server subsystem utilises the process csrss.exe for managing the majority of the graphical instruction sets under the Microsoft Windows operating system. Csrss.exe controls threading and Win32 console window features

PPS
I have tried these experiments on a computer with completely unrelated hardware and seen the same results.

PPS
Please avoid posting if you are only going to give general comments on speed. 
I am particular interested in conditions that do not CPUSaturate when you have a clean drawing with 120 simples dimensions on it. I want DesignCAD and V20 in particular to succeed.

DrollTroll

  • Kindly Curmudgeon
  • Administrator
  • *****
  • Posts: 4091
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #1 on: September 03, 2010, 07:23:16 AM »
Thanks Clive, that's an interesting analysis. Can you post your system specs, please?
2016 marks my 24th year in DesignCAD-Land!

bdeck

  • Hero Member
  • *****
  • Posts: 780
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #2 on: September 03, 2010, 07:42:19 AM »
Clive and DT,

If you explode each dimension and then define it as a group there is no slowdown.

I'm still having trouble understanding why improving conversion to acad required changing the internal structure of the dcad file in version 18.

BD

corlett

  • Jr. Member
  • **
  • Posts: 95
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #3 on: September 03, 2010, 07:57:37 AM »
Hi DrollTroll

I have an AMD Athlon 2500+CPU 1.83 Ghz 1.0GB Ram Running XP Service Pack 3 GeForce FX 5500
This is no speedster but not a bag of bolts either.

My clam that I tried it on a different machine was a mistake. I have now checked properly and its actually a similar machine.
AMD Athlon 2600+CPU 2.08 Ghz 1.0GB Ram Running XP Service Pack 3 GeForce FX 5200, not the Intel machine I thought it was.

Perhaps I can find an Intel machine and run a copy on that. If I can get another 15 day license :-)

Clive

PS
This is all part of my desire to migrate to V20.  I now have a copy which I intend to use it for file conversions and 3D work But I handle large dimensioned drawings so I can't cope with the speed reduction.

corlett

  • Jr. Member
  • **
  • Posts: 95
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #4 on: September 03, 2010, 08:04:24 AM »
Hi bdeck

1. Simple Dimension, Array 60 x 20, Selectx3n CPUSaturation
2. Simple Dimension, Explode, Select, Group, Array 60x20, Selectx3, no slowdown

Clive

DrollTroll

  • Kindly Curmudgeon
  • Administrator
  • *****
  • Posts: 4091
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #5 on: September 03, 2010, 08:57:24 AM »
Clive, email me your serial number. I can extend your trial.
2016 marks my 24th year in DesignCAD-Land!

corlett

  • Jr. Member
  • **
  • Posts: 95
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #6 on: September 03, 2010, 09:01:41 AM »
Hi DrollTroll

In reply to; what hardware?

I have downloaded a 15 day trial or V20 to a new PC and the symptoms are the same.

A Dell: Intel Core2 Quad CPU Q8300@2500Ghz - 4 Gb Ram - Graphics: Intel 64I Express Chipset.
Windows 7 Home Premium 64bit.

The test was
1. Domension, Select, Array 20x60, Select x3.  Slows to a crawl.
2. Box ']', Select Array 100x100, Select x3, near instant selection, no speed reduction.

It looks to be hardware Independent.

Clive


PS
The WindowsTaskManager in windows7 with quad cores shows CPU saturation as 25%, which I take to be one core swamped. But more interesting it does not  look like it is capable of giving real time process usage, as it only reports the process/CPU percentage on one process at a time.


corlett

  • Jr. Member
  • **
  • Posts: 95
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #7 on: September 03, 2010, 09:08:40 AM »
Thanks for the offer.

I have purchased a full license for one copy V20 on my machine, so there is no problem for me.

I have installed 15day copies on two more machines, to do my tests.

If it would help the new intel machine is perhaps the most-different and therefore the most objective to test on and that copy is
Serial number:    xxxxxxxxxxxxxxxxxxxxxxxxx
Activation Code:  xxxxxxxxxxxxxxxxxxxx

Oops!
It is a 15 day trial I gave it no care, sorry

Clive
« Last Edit: September 03, 2010, 09:15:51 AM by corlett »

dcadRob

  • Hero Member
  • *****
  • Posts: 688
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #8 on: September 03, 2010, 09:13:06 AM »
Posting serial numbers and activation codes on a forum ?? You might want to edit that post.

Dr PR

  • Hero Member
  • *****
  • Posts: 5378
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #9 on: September 03, 2010, 10:07:00 PM »
corlett,

I run a 3 GHz XP SP3 machine with a 32 bit Intel single core Pentium and a Vista 64 SP1 machine with a 2.6 GHz 64 bit dual core Pentium. Both systems use nVidia GeForce video cards. Task Manager shows both CPU cores active in the dual core machine when DesignCAD is operating, but activity is different in the two. I assume one core is the OS and the other handles applications.

Edit 5 Sep. 2010: The XP machine has a single core "hyperthreaded" CPU. This lets the CPU simulate a dual processor architecture. As a consequence, Task Manager shows two CPU windows, even though there is only one actual CPU. DesignCAD runs in one of these windows, so CPU saturation appears as 50% CPU activity, although I assume this is really all of the CPU cycles if no other process is being hyperthreaded.

You did not say how you selected the dimensions. This matters! If you point and left click selections can talke a long time. Pointing and right clicking (gravity snap) is MUCH faster. You can also drag a selection box around objects to select them.

For example, on the Vista machine left clicking once in a drawing with 3600 dimensions saturates the CPU for 31 seconds - the program is essentially dead for half a minute. Right clicking (gravity snap) once does not saturate the CPU - selection is instantaneous.

Another thing that slows down the program is operating in Point Select mode (CTRL 1). Each point in selected objects is marked with a little square. This can cause selection (redraw) to take MANY times longer.

Another show stopper is working with multiple windows open in 3D mode. Display time is proportional to the number of windows being redrawn.

****

I tried to repeat your observations on the Vista 64 machine running V20.0. There are two copies of csrss.exe running. Note: this machine has no network connections, and 243 of 244 Vista startup process have been terminated, permanently. DesignCAD is the only application running.

Note: just moving the cursor saturates the CPU - Dcad.exe uses 50% of CPU cycles - but it stops immediately when I stop moving the cursor.

I drew a line and then dimensioned it with a linear dimension - I think this is the "simple dimension" you are talking about. Then I created an array of 120 copies of the line and dimension. Selecting a single instance of the dimension causes NO change in either of the CPU% for either csrss.exe - it is always "00." Quickly left clicking to select three dimensions in a row does cause Dcad20.exe CPU useage to increase to as high as 36%, but only momentarily.

I made a 10X copy of the 120 dimensions -> 1200 copies of the dimension. Rapidly selecting among these dimensions occasionally causes a slight increase of CPU useage of one copy of csrss.exe - to 1% or 2% of CPU cycles. Dcad.exe does saturate the CPU for 3 seconds if I left click three times. Right clicking is instantaneous.

I made 12,000 copies: left clicking caused 50% saturation (Dcad.exe) for 31 seconds - no csrss.exe activity. Right clicking was instantaneous.

I restared DesignCAD and created a drawing with 1000 lines (V). Left click three times and selection was instantaneous.

100,000 copies: left click three times was instantaneous.

1,000,000 copies: left click three times tied up the CPU for 6 seconds.

10,000,000 copies: array command failed.

Note: these tests were in 2D mode, with 2D select mode, and Point Select mode turned off.

****

I then repeated these steps on the XP SP3 machine. Note: this machine has an active network connection and all default XP SP3 processes are active.

Only one copy of csrss.exe running.

120 copies of the dimension: left clicking three times causes Dcad.exe to use 10-20% of CPU cycles, and csrss.exe uses about 15%. Execution stops immediately after the last click.

1200 copies: left clicking three times, Dcad.exe 29% and csrss.exe 27% for 8 seconds. Right click (gravity snap) causes Dcad.exe to use about 24% for 1-2 seconds, and csrss.exe uses about 23% for 1-2 seconds. It looks like the two processes use 50% of CPU cycles.

12,000 copies: left clicking three times, Dcad.exe 27% and csrss.exe 23% for 81 seconds. Right click (gravity snap) causes Dcad.exe to use about 27%  and csrss.exe uses about 23% for  9 seconds.

1000 lines: Left click 3 times  - Dcad.exe 20% momentarily. No csrss.exe activity.

100,000 lines: Left click 3 times  - Dcad.exe 20% momentarily. No csrss.exe activity.

1,000,000 lines: Left click 3 times  - Dcad.exe 50% CPU cycles for 10 seconds.

****

The time required for left click selection is proportional to the number of copies of the dimensions.

My observations on the XP machine corroborate yours - csrss.exe is not active if only lines are selected. However csrss.exe is not significantly active with dimensions on the Vista 64 machine.

One last thing - on various speed tests we have seen great differences between similar machines for the same tasks. There is more to it than CPU clock speed.

« Last Edit: September 05, 2010, 01:53:01 PM by Dr PR »
DesignCAD user since 1987

corlett

  • Jr. Member
  • **
  • Posts: 95
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #10 on: September 06, 2010, 01:57:23 AM »
Hi DR PR

"You did not say how you selected the dimensions. This matters! If you point and left click selections can talke a long time. Pointing and right clicking (gravity snap) is MUCH faster. You can also drag a selection box around objects to select them."

I completely concur about the speed of selection.  I used the LeftClick.
Although other selecting options are available and faster, LeftClick is a very important task.

Thanks for your contribution. 
If you do not saturate your CPU like I do with my three machines, what is going on.

Just to shoot the network connection thing down.  I disconnected my network connection and repeated my 120 dimension CPUSaturation test and got the same saturated result with Kernel times maxed and csrss.exe also maxed out.

Clive

Dr PR

  • Hero Member
  • *****
  • Posts: 5378
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #11 on: September 06, 2010, 11:20:44 AM »
corlett,

There are a number of quirks about DesignCAD (actually, every program I have used) that you learn to work around.

The difference between left click and right click (gravity snap) object selection is interesting. In both cases the program has to find the closest object to the cursor. You would think this was the same task, but why is gravity snap MUCH faster than left click? If DT can figure that one out he might discover a problem that is slowing down other processes in the program.

I decided to repeat these tests in DesignCAD V15.3 and V17.2.

1. 120 copies of dimensions - no noticeable difference between left and right click selections. Selection was instantaneous.

2. 1200 copies - no noticeable difference between left and right click selections. Selection was almost instantaneous. Less than 1 second when Dcad.exe and csrss.exe used 50% of hyperthreaded CPU time (saturation).

3. 12,000 copies  - no noticeable difference between left and right click selections. Selection was almost instantaneous. Less than 1 second when Dcad.exe and csrss.exe used 50% of hyperthreaded CPU time (saturation).

Again, Dcad.exe and csrss.exe consume 50% of hyperthreaded CPU time while the screen is being redrawn (selection). Since there are two hyperthreaded processes running (Windows and DesignCAD) this represents CPU saturation.

Also, in both versions, moving the mouse does not saturate the CPU - in fact, csrss.exe shows no activity with mouse movement.

Also, the Info Box opens instantaneously in both V15 and V17 when all 12,000 copies are selected. It takes 6 seconds in V20.

I saved the 12,000 dimension array from V17.2 and opened it in V20.0. The V17 file was 7.3 Mbytes and the V20 file was 7.2 Mbytes. Apparently the slowdown is not caused by more points in dimensions or larger file sizes. However, left click three times in V20.0 took about a minute and a half to complete!

****

Clearly, there was a big screw up in V18, and it continues into later versions. This happened about the time IMSI started farming programming out to Elbonia. The most noticeable and objectionable manifestation is the EXTREME slowness of opening the Info Box when a large number of objects are selected. This can take ten minutes or more in a 100 Mbyte file! As it happens, this is when TABS on the right side of the screen were introduced, with the Info Box on one of them. Also, this is when dimensions were reworked to be mostly AutoCRUD compatible. A real mess!

I suspect the problem is associated with the screen redraw routines. There are several known problems here. Everything is redrawn twice in all windows. With all four 3D windows open selections take four times as long as for a single window. Even things like zooming in one window causes all the other windows to redraw - totally unnecessary! You can improve speed by closing all but one window or zooming unnecessary windows into a blank portion of the drawing (so there is nothing to redraw). Turn off Point Select mode when working with large drawings (a severe handicap when working).

Another intresting point - if you zoom a window into a blank portion of the drawing redraw time is instantaneous. So it is not the process of determining what should appear on the scree that is the slowdown - this is the same whether the screen is zoomed in to show nothing or out to show everything. Again, the culpret seems to be associated with screen redraw. However, it amy not be the redraw process itself, since opening the Info Box does not cause screen redraw (or does it?).

I also suspect that the dimension text plays a big part in the slowdown. In a separate display refresh test (posted elsewhere on the forum) text had a large effect on display refresh time. I haven't experimented with font types. However, the Info Box slowdown is not related to fonts or dimensions. It happens in large file with no text or dimensions.

****

For what it is worth, I haven't seen much interference from the network connection on the XP machine. However, periodically the network software and email program will make an inquiry from the server to see if there is any new mail. This can slow things down if there is a lot of new email or large attachments. Unplugging the cable only increases the delay because the program will repeat the attempt to make the connection. The only way to prevent this is to shut down all network related software. This means temporarily disabling every network related process from the system management software in the Control Panel. It should all restart when the machine is rebooted.

Again, having said this, the network connection really isn't a problem most of the time. However, if something unexpectedly takes a really long time during a test, repeat the operation just to be sure there wasn't outside interference.

****

Be careful comparing CPU saturation on different machines, especially when the "hyperthread" smoke and mirrors is involved. We (forum members) have noticed significant timing differences between similar machines. This has been hashed through several times, and all proposed hypotheses to explain the differences have proven inadequate. Figure this one out and you get a gold star!
DesignCAD user since 1987

corlett

  • Jr. Member
  • **
  • Posts: 95
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #12 on: September 07, 2010, 01:36:45 AM »
DrPR

Wow!

I just wanted to know how I could migrate to V20 from V16.

With things as they are I have a fully functioning CAD system (V16) so I will stick with this until things change. 

My main function is to Design instruments and I will now get on with that and look out for V21 to see if things have changed.

See you all next summer. Clive

dcadRob

  • Hero Member
  • *****
  • Posts: 688
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #13 on: September 07, 2010, 04:40:29 AM »
corlett,

The V20 version is a lot better than these guys make it sound. It's actually good and certainly worth many times the $100 price. The 20.1 update, coming out soon, may fix some outstanding issues. Check back in a month.

corlett

  • Jr. Member
  • **
  • Posts: 95
Re: Objective tests, show csrss.exe hogging the CPU when using dimensions
« Reply #14 on: September 07, 2010, 05:52:45 AM »
Thanks dcadRob

I can not say this loudly enough. " I think DesignCAD is great ".  I am with you guys. I have been a user since V4, I have 7000 drawing created by it and large complex 3D models to boot. Please do not see my original post as a winge.  I thought I had seen something odd with CPUSaturation and scrss.exe and wanted to share.

But, and its a small but, I work with large drawing with many dimensions on them and, practically seeking, I can't wait a second for every left click selection.  Thats it, thats my only beef.

Look I think its so good I even bought a copy of V20, just for 3D work.

Clive

PS
I wait in hope of being able to use it fully.  I will look out for any update but I suspect my problem is little piece of inefficient sub-system code and will not be fixed in an update.