Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Optimizing performance of large assembly loading times
marcus_wong438
Member Posts: 2 EDU
Hi, I had a question about the best way to manage large assemblies such that loading times are bearable. The current way my team's projects are set up is by having a few sub-assemblies in folders of the document, while there is a master assembly of the complete product that uses these sub-assemblies. All of this is a part of a single document.
I am unsure if this rumor is true, but I heard from someone that an individual Onshape document is allocated a single worker thread from Onshape's servers. If this is the case, would it be beneficial to have sub-assemblies in separate documents while the main document derives these assemblies into a master assembly? Therefore, when a change is made, only the document of the subassembly needs to do a complete regeneration instead of regenerating the entire large assembly that contains hundreds of parts.
If this is not true however, what would be the most optimal way to organize large projects such that documents can be loaded in faster for weaker client computers?
I am unsure if this rumor is true, but I heard from someone that an individual Onshape document is allocated a single worker thread from Onshape's servers. If this is the case, would it be beneficial to have sub-assemblies in separate documents while the main document derives these assemblies into a master assembly? Therefore, when a change is made, only the document of the subassembly needs to do a complete regeneration instead of regenerating the entire large assembly that contains hundreds of parts.
If this is not true however, what would be the most optimal way to organize large projects such that documents can be loaded in faster for weaker client computers?
0
Answers
That said, it is a best practice to break up a large design into multiple documents, for all sorts of other reasons (some reasons are more "obvious" like not having to update all referencing tabs on every change, the way we do if the tabs are in the same workspace, and some reasons are more "internal").
"That said, it is a best practice to break up a large design into multiple documents"
Is there a learning tool or example that illustrates this?
I currently have a document with 1031 instances in the assembly and I need to mirror it and change it….whereas I have learned to build new part studios in context and derive into the new part studio any parts I want and change the name in order to edit specific parts and then insert the new named part into the assembly and perhaps delete the old named part….I am not sure this approach is the best to follow for the mirror of the whole assembly.
Even breaking the large assembly into subassembly seems to me would add regen time as perhaps the software would need back into the old large assembly and then split off into the subassembly to make any change.