My Sugglish Computer Analysis

[TheKitchenAbode]

For my system configuration 70 chandeliers is reasonable. Could tolerate 100 but not for long.

 

Make sure to close the camera view before deleting/adding chandeliers.

 

If enough users report their Chandeliers I will compile and rank the configurations. Will assign, say form 1-10 Chandeliers. Will make a small Chandelier Icon and you can display these in your system configuration description at the bottom of your postings.

[ACADuser]

70 is too slow for me, 50 is tolerable but jumpy.

30 is closer to everyday workable for me.

 

Nice test.

[HumbleChief]

1 hour ago, ACADuser said:

70 is too slow for me, 50 is tolerable but jumpy.

30 is closer to everyday workable for me.

 

Nice test.

Same here

[DRAWZILLA]

 70 is ok, but not more, just a little slow, but I also turned on shadows, bloom, ambient, I also set up my video card using chief.

[Alaskan_Son]

24 minutes ago, solver said:

...creating the camera view. About 20 seconds.

 

Took my system twice that long.  Good thing I don't typically deal with very large plans. 

 

EDIT:  Tested a 2nd and 3rd time.  The 2nd time it only took 26-27 seconds.  For the 3rd test I went in and changed Hardware Edge Smoothing from Low to None and that made no difference at all...still took 26-27 seconds.

[Joe_Carrick]

It may be that the new "Undo/Redo" settings in X9 are having an effect.  The higher the settings, the more disk I/O and swapping might be required.  I believe Chief is making a copy of the model in memory for each change to the model and saving it to disk.  Depending on the location and size of the swap file, this could result in a very large "Undo Stack" and result in memory being written to disk (probably an HHD.  If I'm correct then reducing the number of "Undo's" could result in much better performance.  It might also be possible to increase the size of the "Cache".

[HumbleChief]

Just now, Joe_Carrick said:

It may be that the new "Undo/Redo" settings in X9 are having an effect.  The higher the settings, the more disk I/O and swapping might be required.  I believe Chief is making a copy of the model in memory for each change to the model and saving it to disk.  Depending on the location and size of the swap file, this could result in a very large "Undo Stack" and result in memory being written to disk (probably an HHD.  If I'm correct then reducing the number of "Undo's" could result in much better performance.

BUT then you'd only have a limited number of undo's -correct? Us boneheads need our undo's but I'll try with fewer.

[SCI_Design]

Great test!  One interesting thing I noticed as I played with it - My computer would run it just fine with all 400 chandeliers in the plan as long as I was only looking at say 20-30 at a time.  In other words, if my camera view only was viewing across the edge of the group it ran fast and smooth.  If I zoomed out to include more chandeliers into my screen view it slowed down.  The more I zoomed out, the slower it went.

Also noted:  I downloaded the plan and opened it from my regular drive.  But when I "Saved As" the file to the SSD and operated the plan from that, there was a substantial improvement.

[Joe_Carrick]

8 minutes ago, HumbleChief said:

BUT then you'd only have a limited number of undo's -correct? Us boneheads need our undo's but I'll try with fewer.

Larry,

You can also go into Preferences and change the Undo Folder to a Folder on your SSD which should help a lot.  I have it set there and I limit my undo stack to 12. 

[HumbleChief]

Just now, Joe_Carrick said:

Larry,

You can also go into Preferences and change the Undo Folder to a Folder on your SSD which should help a lot.  I have it set there and I limit my undo stack to 12. 

Same exact setting(s) here.

[Joe_Carrick]

Just now, HumbleChief said:

Same exact setting(s) here.

Try 6 and see what happens.

[TheKitchenAbode]

Just got back in. Thank you to those who ran the Stress Test. Hopefully more users will participate so I will have enough results to establish some generalities. One thing that will definitely effect our results as compared to one another is the resolution of the monitor you are using. For mine, my primary monitor is 1680 X 1050 and my secondary monitor is 1440 X 900. For this test, those running at much higher resolutions will likely find their manageable chandelier level being impacted by all those extra pixels their GPU has to process. Keep in mind that doubling the pixel width & height will quadruple the number of pixels.

 

Possibly someone running a higher resolution could drop their resolution and rerun the stress test to see what the impact really is.

 

Thanks once again and keep those tests results coming in.

 

[TheKitchenAbode]

Just ran the test with my resolution reduced to 800 X 600. Did not seem to have any noticeable effect compared to my native resolution of 1680 X 1050. Would seem to indicate that the GPU processes everything regardless of the resolution setting. This is definitely different than how a game is treated, the lower the resolution the higher the frame rate. Possibly this is related to how Open GL works.

[TheKitchenAbode]

For myself with camera settings such as Bloom, Shadows On and Ambient Occlusion there was a noticeable difference in how long it took to get my Rotate Cursor to function smoothly again after doing a zoom in or out, about a 3 sec delay. As has been reported by others, if I zoom in then things get faster, the less number of objects in the viewable window the smoother the rotate. This also resulted in a reduction in the lag I mentioned in my other statement.

 

Another interesting observation was that my GPU Usage was significantly impacted by the zoom level. If all the chandeliers were visible my GPU usage during a rotate was very low around 16%. When I zoomed in and rotated my GPU usage was up at 60% or more.

[TheKitchenAbode]

Another interesting fact is that a outside camera view of the Grandview plan reports 1,137,364 surfaces. It comes up fast and rotates smoothly. My Chandelier Stress test with only 664,160 surfaces does not run as smooth as the Grandview. Would appear that surface count may not be the only thing going on here.

[yusuf-333]

46 minutes ago, TheKitchenAbode said:

Another interesting fact is that a outside camera view of the Grandview plan reports 1,137,364 surfaces. It comes up fast and rotates smoothly. My Chandelier Stress test with only 664,160 surfaces does not run as smooth as the Grandview. Would appear that surface count may not be the only thing going on here.

I was also obtaining similar results, and was surprised that, it is not the surface count only that maters as most of us believe ....don't know why I didn't mention this in my note yesterday.

BTW, Have you read the manual for other points I was raising? In 3d view defaults setting, surface counts has a setting to bundle a group of surfaces to mono count, though it is only for vector view, it has again a noticeable impact on the overall speed of the model.

[TheKitchenAbode]

34 minutes ago, yusuf-333 said:

I was also obtaining similar results, and was surprised that, it is not the surface count only that maters as most of us believe ....don't know why I didn't mention this in my note yesterday.

BTW, Have you read the manual for other points I was raising? In 3d view defaults setting, surface counts has a setting to bundle a group of surfaces to mono count, though it is only for vector view, it has again a noticeable impact on the overall speed of the model.

 

Agree, I also have had my doubts about how impactful the surface count is at least concerning moving within a 3D camera view. It may though have an impact when you get that Building Model notification prior to the 3D view coming up. 

[Richard_Morrison]

Just for grins, I decided to run a comparison between Archicad 20 & Chief X9. I exported the chandelier in 3DS, and imported as a symbol into Archicad. I checked the number of polygons, and it was about the same: 3.8 million. Taking a camera view, after the initial model building, which took a few seconds to appear, 3D camera views were virtually instantaneous thereafter, even for new cameras created.  Generating a new section/elevation, where the view depth included all 400 chandeliers, took about 2 minutes initially, then edits and zooms had maybe a two second lag max to regenerate. If the elevation depth were limited to one row (20 chandeliers), it was maybe 10 secs for the initial screen build, and pretty instantaneous thereafter. Due to background processing and tabbed views, I could make an edit in plan, then jump to 3D view or to elevation with maybe a one-second lag for a screen refresh.  It would be no problem at all doing a project with all 400 chandeliers. Graphisoft clearly has paid attention to dealing with large models, and Chief could learn something from them.

[TheKitchenAbode]

Ok, I have completed my testing and evaluation concerning the impact of Surface count and performance.

 

Do the number of surfaces impact on performance ? - Yes

Is it just this simple surface count that determines it ? - No

 

Then what is it? - It's whether or not the surfaces are singular or packed together in Architectural Blocks or Symbols.

 

Individual objects/elements are the fastest to process.

 

Surfaces contained within Architectural Blocks or Symbols are not directly accessible for processing, they must be unpacked in some manner first. From my what I can determine this takes 3-4 times the processing than if they were not in an Architectural Block or Symbol. This gets even worse when these are nested together, blocks within blocks.

 

Does the surface property make a difference ? - I found no discernable difference in performance as it relates to the surface/material properties.

 

Will a faster GPU help? - Yes and No

 

Both the CPU and GPU are involved, the surfaces are processed by the CPU first before being sent to the GPU, this process appears to be single threaded.

 

OK, but once the 3D view has been generated then my GPU will be able to go to work - No

 

Even though the model is now in the GPU your CPU is still involved as you move within the model or make changes. Those surfaces still need to be processed or when changes are made the 3D model must be rebuilt.

 

Is there any way to overcome/minimize this ? - Yes

 

1.) If possible use as few Architectural blocks and Symbols as possible.

2.) Use the Layer Set Display Options to turn off the display of unnecessary things.

 

CA only processes the surfaces that are within the turned-on Layer Set Display Options. This is the most effective method I have found when dealing with sluggish performance, turn off those unneeded layers.

 

Just an additional side note about those blocks & symbols, they also have a similar effect on many other CA functions such as copy, undo/redo, move and anything else that

involves a model rebuild.

 

 

Hope this helps.

 

 

 

 

 

 

 

 

 

[DRAWZILLA]

Thanks or all your time on this Graham, it all makes since to me. Moral of the story is get as much CPU and video card that you can afford, as it has always been.

[TheKitchenAbode]

Just now, DRAWZILLA said:

Thanks or all your time on this Graham, it all makes since to me. Moral of the story is get as much CPU and video card that you can afford, as it has always been.

 

Thanks Perry - In general that is definitely the rule. However, the type & combination will and can have a significant effect on how much of an improvement will actually be realized. If one is to configure the best possible system, regardless of budget large or small, then understanding the CPU & GPU interactions, single thread versus multi thread operations and how your software actually functions is crucial. You could easily be spending a significant number of $$$'s and end up going nowhere.

 

For example, with that Chandelier Stress Test, my GPU is fairly low on the performance ranking scale, despite that fact I was achieving similar camera view performance as those with significantly greater GPU performing cards, they should have blown me out of the water . Why not? because those other cards are most likely being limited by the CPU due to it being part of the camera view function and the process being single threaded. Even my 620 integrated graphics HP Spectra 360 performs in camera view about the same as my main system, just takes a bit longer to build the 3D Model before the camera view displays.

[TheKitchenAbode]

Sorry about my persistence on this subject. When some users ran the Chandelier Stress Test they found that their camera view performance improved as they zoomed in on the Chandeliers. I believe I can now explain this behavior.

 

The camera view function requires both the CPU and the GPU, when all the Chandeliers are within the camera view the CPU must process all of the displayed elements. However when you zoom in the CPU only processes the elements contained within the view and as such there are far less elements to process. Initially when the CPU has to process all of the elements the GPU sits waiting for them and as such the motion is jerky. As you zoom in and the CPU has to process fewer elements it will reach a point where the flow from the CPU to the GPU is sufficient enough that the GPU does not have to wait anymore. Motion is now smooth. The CPU is no longer the bottleneck in the process, they are now balanced. The next bottleneck will be when the CPU can flow data at a greater rate than the GPU can process, now the GPU is the limiting factor.

 

From what I can tell the CPU processing side of this is single threaded, therefore it is important to choose a CPU that has the highest single thread performance if one wishes to get the most out of their GPU's.

[JJohnson]

Surfaces contained within Architectural Blocks or Symbols are not directly accessible for processing, they must be unpacked in some manner first. From my what I can determine this takes 3-4 times the processing than if they were not in an Architectural Block or Symbol. This gets even worse when these are nested together, blocks within blocks

 

 

This is interesting.  On my computer, a perspective overview of 70 chandeliers takes 3 sec., but if I select and block those same 70 ch.s it takes 7 sec.

I think I will go back to my detail pages, which slow down work in layout views, and see what has been sent in as blocks and perhaps

some undoing blocks in in order.

[TheKitchenAbode]

31 minutes ago, JJohnson said:

Surfaces contained within Architectural Blocks or Symbols are not directly accessible for processing, they must be unpacked in some manner first. From my what I can determine this takes 3-4 times the processing than if they were not in an Architectural Block or Symbol. This gets even worse when these are nested together, blocks within blocks

 

 

This is interesting.  On my computer, a perspective overview of 70 chandeliers takes 3 sec., but if I select and block those same 70 ch.s it takes 7 sec.

I think I will go back to my detail pages, which slow down work in layout views, and see what has been sent in as blocks and perhaps

some undoing blocks in in order.

 

The other option if you do not need to see them is to turn off the displayer layer that they are in or move them to a separate layer so you can control just their display without effecting anything else.

[javatom]

Preference/render panel only has options for hardware edge smoothing of low, med, high.  I do not see any numbering selections and I can not find the software edge smoothing control at all.