My Sugglish Computer Analysis

[HumbleChief]

Great stuff Graham and really appreciate your time regarding this issue. I have concluded that Chief does a LOT of work in the background and that will probably not change as I feel it goes to the core of how Chief is programmed. I would like there to be a very efficient software engine under the hood but don't think that's gonna happen.

 

I have also concluded that there are 3 factors that effect speed in Chief - CPU, CPU, and CPU. Today's modern GPU's are more than capable of handling Chief's 3D models but it needs a fast CPU to generate the data that the GPU will display and any slowing in the CPU stage will show up everywhere. Also as has been pointed out CPU core speed seems to be more important than number of cores for every day computing. I really think that's true. I have a bunch of cores but think they might only be good for RayTracing which I do very little of anymore.

 

The plan I posted was indeed an older plan but I see similar lags in newer plans when the plans get large. I think my older system is just not that fast anymore. I'll test that this weekend when I get a couple of new Xeons but I am not that optimistic to be honest.

 

If I were to build a system tomorrow I would look into extreme overclocking a 6700 or a 7700 with a couple M.2 drives (or whatever the fastest drives there are) set up in a RAID 0 configuration, a modest GPU like maybe a 1070, and 32 MB fast memory. Probably cost$2000 when all said and done.

 

I'll post results when I install those new Xeons because I think this info helps everyone a ton when choosing a Chief system.

[Renerabbitt]

Even with an overclocked 14 core xeon my system lags when rebuilding a complex model, as Humble chief mentioned the cores don't necessarily matter though I thought the massive cache that comes with these high core count cpu's would make a difference. After reading these posts I'm curious to see if locking layers would help anything and/or if manually rebuilding would change anything...One of my biggest gripes is the lack of an UNDO drop down history list, so I could scroll to the change state I want to revert back to

[TheKitchenAbode]

Thanks Larry - From what I can conclude so far is that the demand on hardware is not really that severe. With the Grandview plan my total RAM load is only 6GB and that includes my other programs. The Memory load on my graphics card is only about 2.4GB and that's with the plan, 3 cameras, 2 elevations and another monitor with several windows displayed. I tested the graphics response with about 10 cameras open to push it to use a swap file. There was very little in noticeable response time when the camera view had to be pulled from the swap file and this only effected the initial display of the view, it had no effect on moving within the view once it was displayed as it is now all in the GPU Memory. There is no benefit at all to having a bunch of unused RAM, it's just a waste of money.

 

Concerning the Drives. It only comes into play when you initially load the plan, the first access to a Library section, undo/redo and a file save operation. The first two are one shot deals and no longer have any effect while you are working on the plan. In most circumstance the undo/redo and file save disk read/write operations are just not that much. From what I can see the undo/redo lag is not related to the drive operation, it seems to be this rebuild function that takes place after the fact.

 

Will keep exploring and posting my thoughts

 

[TheKitchenAbode]

10 minutes ago, Renerabbitt said:

Even with an overclocked 14 core xeon my system lags when rebuilding a complex model, after reading these posts I'm curious to see if locking layers would help anything and/or if manually rebuilding would change anything...One of my biggest gripes is the lack of an UNDO drop down history list, so I could scroll to the change state I want to revert back to

 

Locking layers has no effect. It appears to be the number of layers in use and the number of elements on the layer that dictates what has to be processed. I have tested this over and over with the same result. The only hick-up that I can find is that for some reason CA performs a model rebuild even though there is no 3D model being displayed and it only seems to happen with certain elements and not always every time.

 

You can turn off the Auto Rebuild but some functions like undo/redo override this and force a rebuild.

[Renerabbitt]

4 minutes ago, TheKitchenAbode said:

 

Locking layers has no effect. It appears to be the number of layers in use and the number of elements on the layer that dictates what has to be processed. I have tested this over and over with the same result. The only hick-up that I can find is that for some reason CA performs a model rebuild even though there is no 3D model being displayed and it only seems to happen with certain elements and not always every time.

 

You can turn off the Auto Rebuild but some functions like undo/redo override this and force a rebuild.

So often in plan sets I don't need wall or flooring layers, I suppose you could make a streamlined base plan by deleting underlayments in room specs and creating wall assemblies without any layers...this is all good info, thank you!

[SCI_Design]

Graham,

 

  Thanks for your detailed analysis.  Its very similar to the experiences I've had... CA needing to rebuild with nearly every action really slows down the program.  Bigger plans get worse and worse as detail is added or framing is generated.  As you mentioned I've also seen good results with a bigger / faster computer.  More CPU cores, fast SSD, and good GPU's will certainly speed things up.  I've come to expect a $3,500 investment on a new computer every few years to keep things moving fast.  

[TheKitchenAbode]

I've done a bit more experimentation. I'll stick my neck out but it seems to me the Rebuild is a big part of the problem. In my opinion it's too "Dumb of a Function" as it seems to rebuild the entire model regardless of what has actually changed. I uniquely named a material so it would be exclusively assigned to only one couch in the Grandview plan and not used anywhere else in the plan. I clicked the couch with the Rainbow tool, clicked ok and it made no difference to the Rebuild time, it obviously rebuilt everything even though the only thing that was changed was one material on one simple couch. This definitely needs to be corrected if at all possible.

[Chopsaw]

Graham, Thank you so much for the time you have put into this project and I am hoping Chief Architect will take a serious look at this so we can all continue to build larger more detailed plans without crashing our systems or having plan files that are totally unmanageable.  Still cant imagine what kind of a computer you would require to build a fully detailed 30 floor building when you can choke a entry level gaming system with a 20,000 sq ft ranch.

[TheKitchenAbode]

Here is a possible work around for those experiencing a 3D Model Rebuild execution when only working with a plan view. Open up a 3D camera view and set the layer set to "All Off", go back to your plan view and I think you will find that the 3D Model Rebuild will not execute anymore. This assumes you do not have any other 3D cameras open. It seems that there are times when CA does not recognize that there are no 3D Views, so it continues to Rebuild. I've tested this a few times in the Grandview plan and it seems to work.

[ACADuser]

I re opened my Support Case & linked Chief support to this thread starting at post 8 in hopes they will read & respond to this issue.

 

[TheKitchenAbode]

8 minutes ago, ACADuser said:

I re opened my Support Case & linked Chief support to this thread starting at post 8 in hopes they will read & respond to this issue.

 

 

Thanks Alan - I'm certain there is something they can do to at least minimize this. I'm can't believe that they did not encountered this when developing the Grandview plan, unless they are using IBM's Watson. I know the 3D Model Rebuild is necessary but maybe they could make this a background process so at least the program would not hang when this is executing on a complex model.

[HumbleChief]

1 minute ago, TheKitchenAbode said:

 

Thanks Alan - I'm certain there is something they can do to at least minimize this.

There is but they won't. I don't blame them as there's absolutely no ROI to basically re-write huge portions of the code and why? So we don't have to buy faster computers to operate ever more complex software? Not sure what world that is but it's not the one I live in.

 

Besides they already, theoretically, made undoes faster but they are no faster on my machine than they were before. Not being negative, but realistic. Where's the motivation for Chief to invest many, many resources to make their program faster? If there's a quick fix to sloppy code then maybe yes but overall speed boosts? I dunno.

 

Oh wait X9 is faster than X8. Is it really? Is the speed difference perceivable? Anyone done any actual every day testing?

 

Our best hope is that Intel jumps back on the HPDT (high performance desk top) and gets us some rally fast chips for a reasonable cost.

 

Only one man's opinion.

[TheKitchenAbode]

Larry - Understand but I know from experience that it can be a huge task at times to rewrite code and just about every software company tries to avoid this like a pandemic disease. The first approach is always a patch. I'm sure they can come up with something that would at least minimize this, at least concerning the 3D Model Rebuild. Even if not, from what I can see, we can control this from our side through the use of the Layer Set Display Options. Possibly this was always the intent, it was just never explained to us.

[HumbleChief]

1 minute ago, TheKitchenAbode said:

Larry - Understand but I know from experience that it can be a huge task at times to rewrite code and just about every software company tries to avoid this like a pandemic disease. The first approach is always a patch. I'm sure they can come up with something that would at least minimize this, at least concerning the 3D Model Rebuild. Even if not, from what I can see, we can control this from our side through the use of the Layer Set Display Options. Possibly this was always the intent, it was just never explained to us.

Here's hoping but as always I am, at best, cautiously optimistic.

[TheKitchenAbode]

2 minutes ago, HumbleChief said:

Here's hoping but as always I am, at best, cautiously optimistic.

 

That's a step forward

 

[TheKitchenAbode]

Another way of looking at these frustrations is that if one is curious enough it encourages you to dig deep into the program as you attempt to understand what's going on. This often results in a greater understanding of the software and how it functions. In this particular situation I now have a much improved understanding of Layer Sets than I did prior to this. CA may not be perfect, but time and time again it seems that with CA if there's a will then there is a way.

[Alaskan_Son]

Just one additional little thing to think about here...

 

One big thing that comes into play here is face count.  Graham mentioned turning off layers but its really whats on those layers that's important.  For example, you can draw 4 walls, a couple windows, a door, and a roof to create a small house and end up with around 2,000 faces.  You can also very quickly and easily find a Viking cooktop with 20,000 faces.  That means you can have a cooktop that takes 10 times as long to rebuild as an entire house or that you can leave 10 times as much house turned on by just turning off the cooktop.  This same general premise holds true throughout the model.  There are many items with lots of faces that can really slow things down.  Those are the types of things whose layers should be turned off if we don't need them and it absolutely does make a HUGE difference sometimes. 

 

For those that doubt the effectiveness of tuning off layers you can very easily test this too.  Drop one of the aforementioned Viking appliances into one of your plans and use multiple copy to create a good handful of copies (100 or so maybe).  Now create a 3D view.  It will likely take a notable amount of time to build that view.  Now turn off the Fixtures, Interior layer in your camera view set and create the 3D view again.

[TheKitchenAbode]

Michael - Good Point. I think the whole program is structured around these layers, they determine what you see, what CA processes and how you access things during your workflow. How you set them up and what elements you assign to the layer(s) can have a significant impact on how efficiently you and the software function. Hopefully some of the items discussed here will help us better understand the importance of the Layer Sets, their Display Options, how we assign elements to them and how we structure them.

[ACADuser]

Too bad there is not a setting that would make the windows opaque & none of the interior items would come into play with an outside camera view.

 

[TheKitchenAbode]

Just ran a quick test concerning faces. Took a chandelier that has about 9,500 faces and placed in a blank plan. Copied it for 100 units giving a total face count just shy of 1 million. The 3D Model Rebuild took (hanged) for 9 sec. on my system after I clicked OK on the Rainbow DBX.

[TheKitchenAbode]

This is interesting. For the above I had grouped the fixtures in an Architectural block. For interest I unblocked it and it now runs very fast. Would need a bit more playing with to confirm but on the surface, excuse the pun, Blocking elements may also impact on things.

[TheKitchenAbode]

Yep, just blocked and unblock a couple of times. When blocked the 3D Model Rebuild took a lot more time versus them all on their own.

[Joe_Carrick]

Yes, Blocking simply adds another level of complexity. 

1. Blocking sets all the sub-items location as relative to the Block's origin
   1. There is no reduction in Face Count.
   2. Rebuild has to use a transformation matrix to adjust each object's location vs the Block location.
2. Create Symbol OTOH only saves the visible external faces of what's visible
   1. This results in many fewer faces
   2. No transformation matrix is needed since everything is located relative to the 0,0,0 coordinates

The moral of the story is to create symbols (rather than blocks) unless you absolutely need to have access to the original objects.  That is sometimes true but usually it isn't. 

 

Maybe CA could come up with a way of knowing what needs to be rebuilt but it might not be that easy and it could cause other problems. 

[HumbleChief]

CPU, CPU, CPU - sad but a reality with today's as well as yesterday's computers.

[rlackore]

Why does moving a door label, fixture label, etc. in an elevation view force a rebuild? I would think a label could be treated like CAD objects - they simply "overlay" the model and only require a screen refresh - not an entire model rebuild.