Few things generate IT tickets in an architecture practice like a sluggish Revit model the week before a submission. The instinctive diagnosis is usually hardware: the machines are old, so the fix must be new ones.
Sometimes that is true. But before a practice commits to a round of workstation spending, it is worth checking the factors that just as often govern real-world Revit performance.
Model health comes first
Heavily-detailed families, unpurged models, excessive design options, imported CAD geometry and sprawling warnings lists all drag performance down regardless of the hardware underneath.
A model audit, purging unused elements, reviewing warnings, rationalising families and splitting oversized models, frequently recovers more speed than a hardware refresh, at a fraction of the cost.
Storage and network are the hidden bottleneck
Worksharing performance depends heavily on where the central model lives and how fast every workstation can reach it. Ageing file servers, congested switches and Wi-Fi-connected workstations all show up as “Revit being slow”.
Synchronise-with-central times are a useful diagnostic: if they vary wildly across the office, the problem is usually infrastructure rather than individual machines.
When hardware genuinely is the answer
Revit is largely single-threaded for day-to-day modelling, so a smaller number of fast cores beats a large number of slow ones and plentiful memory matters for big models. Rendering and point-cloud work shift the balance towards GPU.
Virtual workstations change the economics again: platforms like Inevidesk let practices provision GPU-accelerated performance per project rather than per desk, which suits fluctuating team sizes.
The right answer starts with measurement rather than assumption and that is a conversation worth having before the purchase orders go out.