<< What happens behind-the-scenes when you interact with a Grasshopper model on ShapeDiver? What's the difference versus doing the same on your desktop? We've heard these questions numerous times so finally we're sharing the full scope.>>
Response time comparison: Desktop (Rhino) vs Cloud (ShapeDiver)
When working with parametric models, many users expect the same swift interaction from ShapeDiver as they experience in Rhino on their desktops. While this is completely understandable, there are many additional steps between the initial parameter change and the final delivery of the solution to your browser.
Below we go into detail about each of these steps, and we provide some insight on our strategies to improve the response times of your ShapeDiver models.
Computation Time & Response Time
In Grasshopper, the main factor determining how fast models are updated is the computation time of a definition. In other words, how much time it takes for Rhino to solve the definition for a specific set of inputs. On top of the computation time, Rhino also takes some time to render the geometry in the viewport, but this is usually a fraction of the computation time.
Computation time is a key value in the ShapeDiver context for two reasons:
Our pricing model is based on it: Free accounts get 5 seconds, PRO accounts get 10 or 30 seconds, Enterprise accounts get unlimited time.
It impacts the performance of your models and therefore plays a strong role in making or breaking the user experience of the ShapeDiver model.
However, computation time is only a subset of the total response time which users experience when changing parameters and interacting with a ShapeDiver model.
The response time represents the total time elapsed between a request from the ShapeDiver model (for example, the end users updating a parameter) and the moment when the solution is received and displayed in the web browser. Overall, this time is the important one to consider for a smooth and enjoyable user experience. From the moment a user tweaks a slider, a number of things happen until the viewer refreshes so let’s break down those steps.
Step 1: Send Request
Immediately after parameter change, a JSON object with the new parameter values is sent from the web browser to our servers. The object itself is quite tiny in size and should hit our servers in a fraction of a second. Bear in mind fluctuations might happen as this depends entirely on the Internet speed and network status of each user, factors that sadly we can’t influence yet.
Developers can find out more about the API calls that are triggered when changing a parameter in our API reference page.
Step 2: Model Processing (Computation Time)
After the parameter update request has successfully arrived, the processing of the model starts. In this step, our servers actually run the Grasshopper definition and compute a solution from it. In other words, we are talking about the computation time of the Grasshopper file stored in our system.
It’s hard to predict computation times, but as a rule of thumb we can assume that the processing on our shared system is about the same as you’d expect on your laptop. PRO customers have access to a shared system with a scalable infrastructure but, again, some minor performance fluctuations might occur when responding to a spike in traffic.
Enterprise customers on the other hand can configure hardware specs according to their needs and give the model processing a significant boost.
Regarding this step, Grasshopper experts can make a huge difference and cut down the overall response time by making their parametric models as efficient as possible. Therefore optimize, optimize, optimize!
Bonus Step: Caching System + CDN
In order to reduce the processing time even further we developed a system that combines caching assets with Content Delivery Networks to achieve blazing fast geometry delivery.
Basically we store all previously computed states for any given model. This means that if a user chooses a parameter combination that has previously been processed by our system, our system no longer has to use the Grasshopper file to generate the result. Instead, a cached solution is fetched and sent.