Fixing Onshape Large Assembly Performance

I've spent over two decades on the line, swapping out spindle bearings while the production scheduler breathes down my neck. When Onshape landed on our shop laptops, I was the guy who had to make it work next to a Bridgeport and a grease pit. The brochure says "seamless real-time collaboration" and "parametric power." The reality? Three recurring nightmares that make you want to throw a mouse at the wall. Here's what they are, why they happen, and how we nail them down.

Nightmare #1: Large Assembly Performance The Five-Cylinder Lurch

Onshape runs entirely in the browser. That means it's at the mercy of your GPU, RAM, and most painfully the server round-trip for every feature recalc. In my shop, we have a 2,500-part press tool that made Onshape choke like a dirty fuel filter. The marketing says "automatic multi-threaded solving." What I saw was a single-core bottleneck on the server side.

Physics of Failure

Onshape uses a client-server architecture where each geometry kernel operation (Boolean, fillet, loft) is solved on the cloud. Under heavy assemblies, the server queues these operations. If your internet has latency above 20ms, the client sits idle waiting for the next chunk. This is especially brutal when you have external references, derived parts, and in-context mates each dependency adds a round trip. The browser's memory heap balloons with triangulation data, and after an hour of heavy rotation, the tab crashes with an "out of memory" error. Chromium-based browsers are slightly better, but Firefox still leaks like a sieve.

Field-Fix Workflow

1. Disable "Auto-rebuild" during rotation. Go to Document settings → Enable lightweight mode on all subassemblies. This forces Onshape to load only bounding boxes for graphics, not the full B-REP. On an 800-part weldment, this cut load time by 40%.
2. Explode the assembly into logical sub‑assemblies. The worst bottleneck is a single top-level assembly with one million mates. Create a "frame" subassembly, a "mechanism" subassembly, and a "covers" subassembly. Use "pattern" components sparingly a linear pattern of 50 bolts will solve faster as a single multibody part with holes, then mirror.
3. Flatten the feature tree. Every fillet or chamfer at the assembly level kills performance. Suppress cosmetic fillets until you're ready to output a drawing. I've seen a 35-second rebuild drop to 4 seconds just by suppressing a knurled surface pattern.
4. Use "Simplify" on imported STEP files. If you've faceted a supplier's CAD to a mesh, Onshape struggles. Convert meshes to surface bodies only when necessary. For visualization, keep them as "mesh" and set drawing view to "hidden line."

One time we had a 2,000-part conveyor assembly that took 90 seconds to regenerate a single external reference change. The culprit? A mate connector referencing a face that had been filleted every regen forced the kernel to recompute both the fillet and the mate. Switched the reference to a plane through the original face, and the regen dropped to 12 seconds.

Nightmare #2: Version Control The "I Changed the Wrong Branch" Trap

Onshape's versioning is Git-inspired, but without the safety net of a local stash. The document is one continuous timeline. Branches and workspaces are managed server-side. If you don't understand the difference between "workspace" and "version," you will lose work. I've seen an entire weekend of redesign disappear because someone pushed a version before the boss had signed off the rollback created an orphaned branch that nobody knew how to retrieve.

Physics of Failure

A "workspace" is a live editing area. A "version" is a snapshot. When you roll back to a previous version, Onshape does not delete the intervening history it creates a new branch. If you then continue editing in that rolled-back workspace, you effectively branch the timeline. Later, when another user updates the original branch, you face a merge conflict that Onshape resolves by either keeping yours or theirs no three-way merge, no diff tool for features. This is a nightmare on a team with five designers all making simultaneous changes.

Field-Approved Version Workflow

1. Name your workspaces by purpose, not date. Instead of "Jim's workspace," use "tooling-modification-v2." Every time you create a branch, write a one-line description in the commit message. The default "updated" message is useless.
2. Lock the master workspace. In the document permissions, set "Can edit only" for team members on the master workspace. Use "Can create and push versions" to prevent accidental pushes. Only the lead engineer merges to master.
3. Before you roll back, create a version of the current state. Right-click on the workspace → "Version." This saves a timestamp so that you can return if the rollback goes bad. I've had to dig into the document history using the "Show history" pane to find a lost feature, and it's painful because you can't filter by user.
4. Use "Compare" before any merge. Onshape's compare tool shows geometry changes in red and green. Do this before hitting "Publish version." If you see a thousand changes, abort and talk to the team.

We now enforce a rule: no branch lives longer than a day. If a modification takes longer, break it into smaller pieces and merge each piece. This reduces the chance of merge hell when two designers both modify the same face offset. We also use the "Reference" feature to share geometry between documents instead of in-context editing it keeps the timeline simpler.

Nightmare #3: FeatureScript The "Why Won't This Curse Work" Learning Curve

FeatureScript is Onshape's custom scripting language for creating custom features. It's not a macro recorder it's a functional language that compiles into geometry kernel calls. The learning curve is steep if you've only ever used Python or VBA. I've had to write a custom sine-wave gear generator for a prototype, and it took three full days of head-scratching.

Physics of Failure

FeatureScript runs on the same cloud servers as the modeling kernel. Every time you change a line of code, it triggers a recompile and a full rebuild of your document. There is no local debugging you rely on `println()` output in the console, which appears after a 2-second delay. The API uses "queries" (like selecting all faces that pass a filter) that return a set of entities, but you must be careful with "identity" every entity has a unique ID that changes if you change a parent feature. So your script that worked perfectly on version A breaks on version B because the face IDs shuffled.

Field-Approved Scripting Workflow

• Start with a simple test part. Create a feature inside a separate document with just a box and a hole. Test every function on that simple geometry. The worst mistake is coding on a production part a single error can crash the document and force a rollback.
• Use the built-in library functions. Onshape has `opCreateEdge` and `opExtrude` that are well-documented. Avoid writing low-level kernel calls unless you have to. The forum has a thread on "parametric hole table" that saved me from writing face-traversal logic.
• Debug with `println` and a loop. Surround your suspicious block with `println("Entering loop")` and `println("Exiting loop")`. Watch the console output carefully errors appear after the geometry has already failed, so you need to catch the moment.
• Version the script. Before each major change to the FeatureScript file, create a version of the document. If the script breaks and you can't revert the script itself (FeatureScript versions are tied to document history), you can roll back the document and re-create the lost code.

One specific field hack: if you need to make a custom gear tooth profile, don't write the profile from scratch. Use the "sketch" approach: create a parametric equation curve in a sketch, then extrude. The sketch engine is more stable than custom FeatureScript geometry generation for complex curves. Only use FeatureScript when you absolutely need to generate geometry that cannot be done with native features (like face fillet patterns with variable radii). The rest of the time, stick to the built-in tools they're tested by thousands, not just the forum crowd.

Community Solutions The Shared Intelligence on the Floor

The Onshape community forum is gold, but you have to know how to search. Don't search "large assembly performance" search "slow mate resolution for pattern components." Stack Exchange style. The best answer often comes from a user who runs a 500-part assembly on a Chromebook connected to 4G. I found a hack to reduce rebuild time by using "suppress" on all subassemblies except the one being edited then use "unsuppress all" right before drawing export.

• Forum favorite: "Enable GPU rasterization" in Chrome, enable `chrome://flags/#enable-gpu-rasterization` and disable "smooth scrolling." This forces the GPU to handle more of the 3D graphics, reducing CPU load. On my shop's ancient Dell workstations, this doubled the frame rate on a 1,200-part assembly.
• Workaround for missing "section view" snap: If the section view doesn't snap to a planar face, create a plane at the exact location and use "view normal to plane" before creating the section. It's an extra step but works every time.
• Batch license deployment: If you're managing 50 seats, don't use individual invites. Set up an SSO provider (Okta, Azure AD) I've seen deployments fail because an engineer forgot to accept the invite and the admin had to reset the pending status manually.

A final word on "cloud-native": Onshape is solid once you accept its constraints. The three nightmares I covered are not deal-killers they're friction points that a seasoned maker can machine away with workarounds. But if your shop runs on 2 Mbps satellite internet, or if you have 100-man projects where merge conflicts are daily, you'll need to invest in discipline and training. I've seen a small team use Onshape to turn around a tooling redesign in four hours flat because they knew exactly which parts to suppress and when to branch.

Keep a fire extinguisher near the CAD station. Not for the motherboard for your sense of humor when the server decides to timeout at 4:48 PM on a Friday.