ASSEMBLY PERFORMANCE: Poisoned Assembly

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

 

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.

 

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.

 

See
http://groups.google.com/group/comp...&q=SuperRebuild&rnum=1&hl=en#3330b3260c7fbbcd

 

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

I'll have to try your version.

 

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.

 

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

 

Maybe efficient coding is not there?

Bo