two identical part studios, wildly different regen times. why?

joshtargo

both of these are in the same document, the lower, faster one is a pure duplicate of the upper, slower part studio. the belt and pulley gen is 1,5s in the first, but 300ms in the second. why could this possibly be?

https://cad.onshape.com/documents/b1ef83e73cb0d34841f69f8f/w/91211999d8343eb8b3a347da/e/679a71616360ce750650a9c1

ilya_baran

The belt&pulley custom feature uses build functions that regenerate other part studios. The first time around they were actually regenerated (hence the 1.5s regen time) and the second time, a cache was used, so they only needed to be brought in, not regenerated (hence the 300ms regen time). If you were to, say, add a feature at the beginning of the first part studio, you should see the shorter regen time there too.

Derek_Van_Allen_BD

https://forum.onshape.com/discussion/comment/132599#Comment_132599

Do all derive based features get some benefit from that same caching? I've noticed that Amalgamate can swing wildly in build time in this same way going from 40 second loads down to 400ms sometimes with the same information encoded in both instances.

joshtargo

@ilya_baran if i were to rewrite it, i should try to do it without an instantiate call? is there any way to hard code a step file when using opimportforeign or do you have to make the user select the file?

Caden_Armstrong

I tried to compare if instantiate vs the most base level import call would compare in performance (sometimes base level calls are slightly faster, like @evDistance is faster than evDistance by a small amount that can compound). But I ran into the same caching conundrum.

If you natively model a part in Onshape, right click the part studio tab and go to "Show code", it shows all the features used to make that part studio. With a bit of fiddling, you can sometimes just copy paste that into a feature studio as a starting point to having a feature without instantiate. I'll do it for sketches. But because of caching, my guess is that it isn't going to be faster.

joshtargo

@Caden_Armstrong I found that importing with opimportforeign can be much faster than deriving sometimes, but i couldn't figure out a way to hardcode the file choices into an enum so the user doesnt have to navigate to the document and pick a step file. is this possible? it would allow a starting base of fairly complex geometry without the overhead of building it.

ilya_baran

@Derek_Van_Allen_BD Yes, deriving benefits from the same mechanism.

@joshtargo You are correct that opImportForeign is faster, but it should be only a very slight difference compared to a part studio with just one import feature. I suggest keeping the custom feature and the part studios it brings in all within one workspace to make sure that std versions stay in sync.