Under The Hood: CAD Performance

TL;DR:

• Fixing common issues, like using an integrated graphics card instead of a discrete one (https://cad.onshape.com/check), or an unreliable network setup can be the easiest way to improve Onshape performance.
• We’re here to help: if you’re running into performance issues, talk to our support.
• When reporting a performance issue to support, if the report is “Onshape is slow”, we’re very unlikely to be able to help, but if the report is something like “At 2:20pm EST moving part studio ### out of a simple document ### took 8 minutes and here’s a branch that reproduces the issue” then we’ll probably be able to do something about it.

Almost every CAD user has run into performance issues at one time or another, regardless of whether they use file-based CAD systems or cloud-based Onshape. The complexity of the tasks that a CAD system must perform makes it almost inevitable that for some users, something is going to be slow, whether it’s creating a big pattern, regenerating a long feature history, or loading a bazillion parts in an assembly. While CAD users have learned to work around some of these issues, no one wants to wait for a slow response from a computer, and in extreme cases, poor CAD performance can completely derail a project.

Many of our customers are driven to offer speed and performance in their products, such as the XING Mobility supercar pictured at the top of this post. Onshape’s development team is no different. We are constantly testing performance, listening to customers, and always have multiple developers working on improving some aspects of performance. These improvements are not usually mentioned in our regular “What’s New” posts, but if you were magically transported back to using 2015 Onshape, it would feel horribly slow in all sorts of ways.

Just in the last few months, we’ve significantly sped up the performance when you:

• Render mate connectors
• Regenerate sheet metal
• Handle multiple configuration references
• Open assemblies with in-context data
• Update drawings
• Interact with large assembly trees

Onshape has also reduced client memory usage and network usage in a number of areas.

The manifestation of poor performance in CAD is usually simple: some operation takes longer to complete than it should. But that simplicity is deceptive: the underlying reasons for a slow operation can be very complicated. In this blog post, I’d like to offer a glimpse at what factors affect Onshape’s performance.

Let’s start by dispelling a few misconceptions that I’ve heard:

• Onshape is slower than my old CAD system because it has to go through the internet.
• This is true if the only performance you care about is how quickly a simple feature responds to a manipulator drag. Most expensive CAD operations are not bound by network bandwidth or latency, in part because we spent a lot of effort to ensure that once a model is loaded only changes are sent over the network.
• Onshape is faster than my old CAD system because it has millions of machines in the cloud computing my fillet.
• On low-end machines, Onshape is likely to be faster: Good luck getting a file-based CAD system to run on a Chromebook. It is also true that for many tasks, we make use of cloud parallelism, and we intend to take increasing advantage of this in the future. But when it comes to regenerating a Part Studio, nine women cannot make a baby in one month.
• Onshape is just as fast on a Chromebook as on a beefy workstation with a nice GPU.
• Memory, CPU and GPU do matter, especially for models with a large number of triangles in their tessellation (curved surfaces and higher-quality tessellation settings lead to many triangles). An expensive “pro” GPU is likely to be *worse* than a good gaming GPU; also, on a laptop, be sure you are using the discrete, rather than the integrated GPU: see our check page.
• If I pay Onshape more money, I’ll get allocated to better servers.
• Usually false, though we can’t promise that this won’t change in the future. There are some resource limits that we sometimes raise for professional users that run into them, but we are generally using the best hardware available for everyone and provision enough of it that users don’t usually interfere with each other.
• If Onshape is slow, it must be X (where X is typically network speed, GPU, or an inherent problem of cloud architecture).
• Onshape can sometimes be slow for a very large number of reasons and we try to make it faster with each release.

Each of these misconceptions has a grain of truth to them, but they are all based on an oversimplified model of Onshape’s performance.

A typical operation performed with Onshape involves your computer, your internet connection, and a large number of Amazon Web Services (AWS) servers on our end. Here are some of the key factors that affect Onshape performance:

If you ever experience poor performance, talk to Onshape Support. They are as good as their reputation – just tell them what is slow and when, being as specific as possible with the action and the time. They can quickly identify document structure patterns known to lead to performance issues, such as long heavy chains of derived features, excessive numbers of tabs in one document, and excessive intra-workspace references. I highly recommend you watch my colleague Philip Thomas’ recent webinar, “Tips and Tricks to Turbocharge Onshape Performance & Speed.”

For less common issues, which require deeper investigation, we (the developers) are directly included in the support process. We can cross-reference your report with our logs to identify causes, and we can trace individual documents using SignalFx to diagnose ongoing issues.

Happy (fast) CADing!