Speed when instantiating many parts

timo_schmid

Hi everyone,
I have a featurescript which instantiates many parts and is therefore running slowly. I tried grouping the parts into closed composite parts, so instead of e.g. 1000 parts, I would have 100 composite parts.
However, this does not significantly increase the speed (neither the actual speed nor the calculated speed when profiling the featureScript). It actually seems to be even slower when using closed composite parts.
Does someone know why it doesn't instantiate faster, despite having much fewer parts? Or is there another way to make the deriving of parts faster?
Thank you,
Timo

EvanReese

I'm not sure, but I'd also like to know. I hope someone drops some knowledge! 

MBartlett21

@timo_schmid
I think the reason it would be still running just as slow with the composite parts is that, internally, the parts are all still separate, and now you have given it more work to do, since it has to group the composite parts again.
What you could try, if the parts are touching, is booleaning groups of parts together, rather than using composite parts. Composite parts do not seem to be very much part of how Onshape works internally.

lana

@timo_schmid
What is the scenario - is it a single reference with 1000 instances or multiple references, e.g. 1000 configurations ? - performance of creating 1000 instances of the same reference is  regeneration of source + pattern with 1000 instances, performance of 1000 configurations is 1000 regenerations of the source.
Do part studios you reference  create only the parts you are instantiating ? - source regeneration regenerates everything.
Do you reference a part studio in the workspace or in a version?  - reference in workspace means that every change in the source causes regeneration of the instantiating part studio, reference in a version can utilize caches better.

timo_schmid

@MBartlett21
Thanks, I think this could be a suitable solution.

@lana
Thanks for the answer, I haven't tried referencing a verstion instead of a workspace yet. 
I'm not sure I understand the question correctly. I have a feature studio with about 30 parts (in one composite). Then I instantiate it between 30 and 300 times, where some have the same configuration and some a different one. I don't know if it internally uses "pattern" for the ones with the same configuration..

lana

In process of instantiation you base part studio is regenerated as many times as the number of different configurations used. the rest of the instances are patterned. That why the difference between 30 and 300 instances is not that big - body pattern is fast.
Try optimizing the base part studio as much as you can.

ilya_baran

Just be sure you make one newInstantiator and many addInstance calls -- if you call newInstantiator for instance, you won't get nearly as good performance.

timo_schmid

@lana & @ilya_baran

Thank you for your answers, they make sense to me, but I cannot reproduce this effect in my featureScript.

When instantiating the same part with the same configuration the calculation time depents very strongly (pretty much linearly) on the number of instances I add.

And in terms of the difference between just one instantiator vs. multiple instantiators, it is surprisingly even faster when using a new instantiator every time...

Here's a link to simple example document that shows this (when profiling the part studio 2).

Am I doing something wrong? Or why does the speed not behave as expected?

Thanks for your help,

Timo

 

lana

That is probably due to Part Studio 1 being small enough and fast to regenerate or load from cache. I can't do much of investigation with shared link. If you could make this document public, I'd take a look.

timo_schmid

@lana

I made the document public now, thanks for your help!

Cheers,

Timo