hi . i have a big script with dynamo for modeling bridge and its runtime is about 8 min. i want to know can i decrease runtime and any suggestion?
for example if i use design script instead of using nodes or any way ?
thanks a lot.
Design script is about the same time as using nodes. They’re both referencing the same libraries in just a direct a manner as far as I understand.
My suggestions are:
- Identify any opportunity to speed up the script using Python. For example using filtered element collectors instead of getting all elements in Dynamo and filtering progressively
- Reduce the number of custom nodes you are using, if any. This can be done using Python in most cases, and will likely allow you to write more direct methods to replace them
- Consider breaking your workflow into separate scripts if possible
- Reduce geometry related nodes as much as possible
- Sometimes bounding boxes can be used instead of solid/detailed geometry
- Use list levels wherever possible to combine parallel branches of your code into one
We don’t really know what your script looks like so it’s hard to say which would help most, but that’s my general tips based on my experience. 8 minutes might not be bad time if it’s a geometrically heavy task.
Worse comes to worse, get Dynamo to send you an email when it’s finished:
3 Likes
Speed is a tough thing to resolve due to the complexity of things involved that are outside of the sphere of influence for Dynamo. Did your computer run out of RAM because you opened a web browser which sent a billion subprocesses? Did someone ping you on teams? Is outlook downloading a large email with an attachment that means your AV/ASW is doing a deeper scan than when idle?
Anything can skew the results.
That said, if in each language you had code perfectly optimized for speed and it’s intricacies, DesignScript will usually win out until one of the following conditions are met:
- Data sets get so large you computer spends more time manipulating the content stored in memory due to the excessive number of page faults than it does actually running calculations. This web-comic from the excellent Wizardzines site sums the technical aspects up better than I ever could: page faults. (Side note: I highly recommend that whole site)
- You offload the effort from Dynamo to the host application (ie: placing 10,000,000 4 point adaptive component panels vs using one repeater component and building a surface).
- Your can take advantage of the core special libraries built to increase processing speed, or add more compute power (ie: multi threading in Python; utilizing dictionaries instead of lists in passing data between nodes; combining six sets of nodes into a single line of design script via in-line functions).
- Your heavy calculations are outsourced from Dynamo to another external tool, usually by get/put requests to external services.
- Your code is written in such a way that you’re having to spend a lot of compute cycles marshaling data between environments. Moving content between Dynamo and a host Host Application (ie: Revit, Civil 3D, Alias, etc.) or other environments (Python, external services, etc.) takes compute effort, and we have very little control as authors on how much time that will take.
If one or more of those things are present due to the nature of your task… Python will likely win the day because it has been optimized for large data sets, efficient memory optimization, and allows for managed background processing. But if that much is going on, and you’re going to have to write external code, a single zero touch node with similar optimization could actually win the day due to the reduced demand on first run… Many of @GavinCrump’s comments above stem directly from one or more of these items; and they’re worth keeping an eye on as you look into the graph. But the best way to reduce run time? Ask the graph where it is slow by using the Tune-Up view extension, which can be downloaded from the package manager, and works for Dynamo 2.5 and up. It will let you see the run time for every node on canvas, so you can test how long each step takes. Do you want to reduce speed? Then build a plan of attack around where it’s slowest rather than where it isn’t (the 10ms saved won’t matter when looking at runtime of 8 minutes).
If you’d like further Dynamo specific discussion on how to optimize runtime, check out session 21 of the Dynamo Office hours which @solamour and I hosted last November. We talk nothing but speed for a full 40 minutes before getting into a live demo where I produced the same results (a sizable collection of triangles in space) using 24 different methods of mostly optimized code. Now none of this took the speed of the host into account, but if you really wanted to build speed, why not offload the compute into an out of process environment and send over the instructions on ‘how to build the bridge’ after you know what you want?
5 Likes