There is a moment every designer knows. You open the master assembly of the machine you have been building for three months, the status bar crawls, and when the model finally appears, rotating it feels like steering a barge in treacle. The first response is usually to blame the computer, and the second is to order a workstation with more cores and a bigger graphics card. I have done both, and I am here to tell you that the hardware is rarely the villain. The real weight in a slow assembly is almost always self-inflicted: part files bloated with history, constraints solving across the whole model on every move, and components loaded fully when only their silhouette is needed.
Why the assembly is slow in the first place
Diagnosing a slow assembly requires understanding the three places the time actually goes. The first is the solver. Every time you drag a component, the constraint solver wants to satisfy every mate across everything it considers live, and a heavy assembly with thousands of relationships solves in a cascade. The second is the graphics pipeline, which has to push every edge and face of every fully-loaded component to the graphics card — and a model with dense fillets and threaded cosmetic geometry has far more edges than your eye needs. The third is disk and memory: every full-load component brings its entire feature tree and history into RAM, and a few hundred such components will exhaust a machine that looked impressive on the spec sheet.
My rule of thumb after years of this: in a machine assembly, roughly eighty percent of the interaction weight comes from twenty percent of the components — the ones with dense geometry or long histories. Everything about my workflow is aimed at finding that twenty percent and deciding, honestly, what it needs to be loaded for. The component that must move kinematically gets solved; the component that just sits there and looks right gets lightweighted without a moment of guilt.
A fast assembly is not one where the computer is fast; it is one where the computer is only doing the work you actually need.
The four levers, in the order I pull them
I arrange my performance playbook as four levers, and I pull them in a fixed order so that the cheap wins come first and the disruptive ones only appear if they must.
The first lever is representations: simplified and lightweight configurations. Before I suppress anything, I ask whether the component even needs to be fully defined for the job at hand. A fastener that appears twenty-four times in the assembly does not need its thread helix or its chamfer detail loaded when I am laying out the frame. A configured representation with the cosmetic detail removed keeps the part associative while cutting its graphics cost by an order of magnitude. This is the lever I pull first, because it changes what the machine has to draw without touching what the model is.
The second lever is selective loading. Most systems let you open a subassembly lightweight, which loads only the envelope and the mates that touch the outside world. Moving a subassembly costs almost nothing then, because the solver only sees its boundary conditions. I teach every new designer in our office to set new components to lightweight by default and to promote a component to fully resolved only when it must move, must be measured, or must be edited — and to demote it back the moment the job is done. The discipline of “resolve on demand, demote on release” is worth more than any hardware upgrade I have ever ordered.
The third lever is suppression, which is the nuclear option and should be treated as inventory: it changes what the assembly is, not merely how it displays. I suppress only what genuinely does not belong in the current working context — a subassembly I am not touching this week, a motion study subject that will be dropped back in later — and I write it down, because a suppressed component is a component someone else will rediscover with alarm. Suppression is for temporary scope control, not for architecture.
The fourth lever is the file itself, and it is the one most people deny needing. A part with a five-hundred-step feature history, full of dead sketches and interlocked equations, loads slowly and solves slowly wherever it is used. I have, on a bad Thursday, recreated a legacy bracket from scratch in a hundred and ten steps and watched the whole machine assembly get measurably lighter. Model hygiene is not a neatness obsession; it is a performance feature that lives in the file.
| Lever | Changes | Cost | Pull when |
|---|---|---|---|
| Representations | What gets drawn | Low, reversible | Always, as standard practice |
| Selective loading | What gets solved | Low, reversible | Always, by default |
| Suppression | What exists in context | Medium, needs notes | Temporary scope control |
| Model hygiene | The file itself | High, one-time | When a part is a permanent anchor |
How you constrain is as important as what you constrain
The subtle killer in heavy assemblies is not the number of components; it is how the constraints are wired. A constrain-the-world culture — where every flange is mated to the origin planes and every screw relates to three parts at once — produces a model that solves beautifully in isolation and collapses into a marathon every time you move a bolt. My strong preference is a parent-child hierarchy that mirrors the machine itself: subassemblies that carry their own internal mates, and between-subassembly relationships kept few and coarse — a pair of concentric faces and a single parallelism, never a web of cross-relationships.
I also ban the habit of opening one giant top-level assembly and dragging everything inside it. A machine that is really four functional modules deserves four subassemblies, decoupled and each lightweight until promoted. When someone tells me their 3,000-part assembly is slow, my first question is almost never about the graphics card. It is “how many components are at the top level?”, and the answer is usually the diagnosis. The assembly tree should be a map of the machine and its maintenance boundaries, not a flat parking lot of parts.
A machine that went from sluggish to usable in a week
Let me tell you about the retrofit conveyor I inherited, because it is a textbook version of every habit above being absent at once. The top-level assembly had four hundred and eighty components, fifty of them directly mated to the origin, and the file took four minutes to open on a workstation most people would happily take home. I refused to touch the geometry for the first two days and instead worked on the structure. We promoted the frame parts to fixed and the rest assembled under seven functional subassemblies: drive, transfer, guarding, sensing, frame, controls, and service. Then we set new defaults to lightweight, rolled the cosmetic detail out of the fasteners, and wrote a one-page practice note explaining which subassemblies were expected to be promoted when.
The result was not dramatic in the headline sense, but it was dramatic in every practical one. Open time went from about four minutes to under forty seconds. Dragging the transfer subassembly no longer triggers a global solve. And when a new junior designer joins the project, the structure itself teaches them where things live, which is a documentation channel I had never counted. We bought no new hardware. This is the part that makes the sales department of the CAD vendor unhappy, and it is exactly the part I want you to believe.
Mistakes I have bought and paid for
| Mistake | Why it backfired | What I do now |
|---|---|---|
| Buying a bigger graphics card first | The weight was solver and file, not raw pixels | Lever order: representations, loading, suppression, file |
| Suppressing without notes | Components rediscovered with alarm later | Suppression logged and time-boxed |
| Mating the world to origins | Every drag triggered a global cascade | Parent-child hierarchy, few coarse cross-mates |
| Keeping fasteners fully detailed | Twenty-four copies of a helix nobody sees | Simplified configurations as standard |
| Reworking only after it hurts | Model hygiene done in panic in deadline week | Hygiene is a weekly habit, not an emergency |
A repeatable workflow, so you do not reinvent it
- Open the assembly and measure first: how many top-level components, how long to open, which ten components eat the most.
- Set lightweight as the default load state for new components, and keep it until a component earns full resolution.
- Restructure the tree into functional subassemblies if it is flat; move the forty-mate offenders into their own subassemblies.
- Apply simplified configurations to the visual-fat components — fasteners, seals, cosmetic threads.
- Promote to fully resolved only what must move or be edited; demote the moment the job is done.
- Run a monthly hygiene pass on the slowest ten files: dead sketches deleted, equations documented, history trimmed where it can be.
None of these steps is glamorous, and that is precisely why they work — they are habits, not heroics. The machine that rotates instantly has not been redesigned; it has been treated with the respect of a designer who knows where the weight actually lives. Next time your assembly crawls, resist the order form for a moment and ask the two questions that have never failed me: what does this need to draw, and what does it need to solve? Answer those honestly, and you will find the computer was never the bottleneck — it was the model’s diet. Feed it less, and it will rotate like the light little machine you always meant it to be.
The habits that keep a big assembly fast forever
All of this works once; the harder question is making it stay working, because assemblies do not slow down on purpose, they slow down by accumulation. A feature added here, a component dropped in there, a supplier’s imported model that arrives with four times the faces it needs — and suddenly the machine you rescued in a week is sluggish again by winter. So let me talk about the steady-state habits, the ones that cost minutes a day and save hours a week.
First, treat supplier and downloaded models as visitors with a curfew. That imported valve block with decorative fillets and a thread represented as a full helical cut is a beautiful thing that does not belong fully loaded in your assembly. The moment it arrives, I give it a simplified configuration — the envelope, the ports, and the mounting faces — and the assembly never sees the expensive version. I have yet to meet a supplier model that could not lose eighty percent of its faces without losing a single functional fact.
Second, keep a performance baseline the way you keep a dimension check. Once a quarter I open the main assemblies and record open time, resident memory, and the count of fully-resolved components. The next quarter, when someone swears the file got slow, we do not argue about feelings — we compare against the baseline and find which component arrived between the dates. A measured baseline turns the slow-down conversation from a blame contest into a hunt, and the hunt always wins.
Third, make the practice notes part of the project kickoff, not part of the autopsy. The page I wrote for the conveyor team — which subassemblies are expected when, where the fasteners are simplified, how to promote and demote — became part of every new project template in the office. New joiners read it before their first drag, and the models stay light because everyone’s default behaviour matches the discipline. The assembly that won’t rotate is almost always a cultural problem wearing a technical costume; you can buy your way out of it once, but you can only maintain it with habit.
I will leave you with a confession that keeps me honest. Every time I catch myself reaching for the specification sheet of a new workstation, I make myself answer whether the model has earned the privilege of the upgrade. Most of the time it has not. The computer is not the patient; the model is. Treat the model’s diet, set the habits, keep the baseline, and the better machine you were about to order becomes an argument you get to have later, with a lighter wallet and a faster assembly.
