ASSEMBLY PERFORMANCE: Poisoned Assembly

Jun 06, 2007 27 Replies
T

Ed,

I'm doing some automated testing that touches on the CTRL-Q thing. It is not clear that rebuilding all vs just rebuilding the top level is faster or slower in assemblies. I posted some preliminary results on Dan Bovinich's mailing list in graph form. One thing that really blew me away was the dependence of rebuild time on pattern part count and how it dropped after patterns exceeded some 200 instances when doing top level rebuilds.

Another thing I have noticed from benchmarking that has been done in the last few days is that certain benchmark's results are faster or slower on different CPUs so that one CPU isn't across the board faster or slower than another.

TOP

Vote
Twitter Facebook LinkedIn
T

Ed,

I also found something bizarre. In my testing rebuild times suddenly got faster after about 200 items in a circular pattern. Didn't think much of it. But after looking closer, SW was simply not patterning more than about 999 items. When the count jumped from 512 to 1024 in my program SW simply didn't add any more to the pattern and so the rebuild time dropped. I checked this manually too.

TOP

P.S. Still might be user error here, there is one more thing to check.

Vote
Twitter Facebook LinkedIn
D

Ed,

I agree that ctrl-Q does nothing for an assembly. However, there is a method that is only available through the API:

'forces rebuild of top assembly and all subassemblies Dim swApp As SldWorks.SldWorks Dim Model As SldWorks.ModelDoc2 Sub main() Set swApp = Application.SldWorks Set Model = swApp.ActiveDoc Model.ForceRebuild3 (False) End Sub

I'm not sure if this is a regular rebuild of each assembly, or a ctrl-Q rebuild or what, but it definitely takes a non-trivial amount of time.

Rant: I have also found on occasion that opening an assembly causes a more thorough rebuild than during normal editing. For example, I can work on an assembly, save and close, then re-open, and I'll have new rebuild errors. To me, this highlights the fact that SW really doesn't have a good grip on what needs to be rebuilt and what doesn't. We wait through unnecessary rebuilds all the time, and go without necessary rebuilds quite often. SW seems to be taking a "best guess" when it comes to marking things for rebuild when it should be possible to "know" when things have actually changed.

Vote
Twitter Facebook LinkedIn
D

TOP wrote in news: snipped-for-privacy@p77g2000hsh.googlegroups.com:

Thanks. I think I remember reading that post now, but the 5th was so long ago...

I'll have to try your version.

Vote
Twitter Facebook LinkedIn
D

Ok, That's a little different from mine as far as rebuild is concerned. It doesn't seem to rebuild subassemblies and components. Setting ForceRebuild3 to FALSE would make the difference.

Vote
Twitter Facebook LinkedIn
T

Some more thoughts on this assembly.

I cleaned it up so it would save and rebuild halfway decently. Then we added a subassembly to it. The assembly had about 1,600 components prior to adding the 3,600 part subassembly. The subassembly will rebuild on it's own in about 3/8 of a second and a full rebuild takes

2 seconds. The main assembly will rebuild in about 27 seconds without the new subassembly and in 56 seconds with it. The full rebuild time on the main assembly goes from 66 seconds to 211 seconds. One has to wonder why adding an assembly that rebuilds in 3/8 of a second to another assembly causes rebuild time to balloon from 27 seconds to 56 seconds.

TOP

Vote
Twitter Facebook LinkedIn
B

Maybe efficient coding is not there?

Bo

Vote
Twitter Facebook LinkedIn

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required