DC Performance Curiosity

Got another one that has me puzzled:

I have a library of 16 fairly complex DCs, enough going on that it takes a moment to process any change.

First curiosity- When all 16 are in one model, a benchmarked change to one (doubling the height) takes 3.8 seconds by my stopwatch. When that same component is copied into a new, blank model, the “thinking” time is cut way back, taking around 1.8s.

So I started digging for the cause, deleting the other 15 and trying again, no change. Purged components, no change. I even compared file sizes for the one that never had other components in it (the 1.8s) with the one that had purged components (the 3.8s), which were virtually the same (1.39MB each, within 3KB when looking closely).

Can anyone account for the extra processing taking place in the slower model? Thanks in advance

BT

Try purging component definitions.

As a whole DCs are grossly inefficient compared to drawing using ruby scripting. I started out using DCs but when I ran against the limitations I wrote my own Ruby scripts and coupled that with an HTLM dialog to change the options. It is a magnitude faster.

This complete model with windows, shutters and all is 466KB. That is another great reason not to use DCs.

1 Like

the number of internal copies of nested components maybe the difference

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.