As the assembly has gotten larger, it’s harder to find the instances that I want and Onshape slows down significantly. I also feel that some parts of the assembly make up logical subassemblies (such as the mount portion of the assembly vs the external intake). However, if I split those into subassemblies I lose the ability to reference their assembly on the common drivetrain and each other - both of which are really useful when everything in this assembly is so related.
It almost seems like in-context modeling of assemblies would be useful in a situation like this. Am I missing an obvious best practice here?
A slightly more modular way to tackle this could be keeping your drivebase and intake subsystems completely separate. Right now, if you want to load either of them, you’ve got to load the entirety of the other (and stuff like those swerve modules definitely take a second to load up).
It probably doesn’t make sense to separate the intake and intake mounting into separate subassemblies - you should have no problem with it all in one document.
If you still want to relate between the two assemblies, you’ve got many options - whether it’s deriving your drivebase rail that already has a hole pattern into your intake part studio and using that to modify your mounting plates, or using in-context modeling to transfer the hole pattern after mating the two assemblies, it should be pretty trivial to do.