Run Speed in Dynamo

Hi All,

I’m wondering what is the best way to construct a script, in terms of the run speed:

  • Normal way using all of the nodes and sub routines into the main script, lacking custom nodes.

  • Similar script, buy grouping some of the sub-processes into custom nodes.

  • Transforming this subprocesses into “Code Blocks” or Python codes.

And finally, whats is faster: normal custom node or zero-touch custom node? (in terms of the run speed)

I’ll appreciate some of guidance related, and if you have some "best practice advices.

Thanks in advance!

My reccomended best practices for speed:

Reduce your data set as quickly and with as few logical functions as possible.
-Filter by phase before area > 0 but less than 100.

Don’t use three logic nodes if you can do it with one.
- And functions make this possible

Ask for something already known and stored in the database instead of asking for customized calculations.
- Good: What is your hosed level
- Bad: get me that geometry, and tell me which level elevation is closet to it’a minimum point, and then return the name of the level which matches that elevation.

Use simple logic functions instead of complicated ones.
- BoundingBox.Intersects is faster than Geometry.Intersects

My beliefs Based on observations not proven in any legitimate scientific method:

Minimize the amount of data which is stored in RAM
- Meaning one node with a 3 second calculation will perform faster on repeated runs than 3 standard or custom nodes with 1 second run times. This appears to be due to the fact that dynamo saves the previous calculation results in the ram (notice how fast ctrl+z regenerates the results for that graph that took 90 seconds to calculate before).

Nested functions feel like they preform faster than loose functions
One code block line stating List.First(List.FilterByBoolMask(items,Element.GetParameterByName(items,“Number”)>10)); feels faster than calling and defining results of each section of code individually.
I haven’t tried defining functions in code blocks with large datasets so they may be further time savers.

Those last too have lean towards the following in terms of processing time from fastest to slowest:
1) Python
2) CodeBlock
3) Nested Custom Nodes
4) Nodes


Thanks @JacobSmall. SOme interesting points here.

Anyone else would like to share some experience?


I have experienced everything that Jacob said, great tips. In addition, it feels faster for me when I have no watch nodes and all nodes have their outputs preview off as well. I don’t know the exact name for this “output preview”, but I believe you are going to undersand what I am saying. I mean that thing that is just like a watch node, that you can turn on or off for each node.

1 Like

Designscripting it.
Node to code helps


1 Like

I cannot like this enough.

If you’re talking about run speed there’s a few things I always consider:

  • Is there a way to perform a task without iterating over an entire list, or if that’s not possible: can I iterate only once over the list?
  • To help with the above Dictionaries and Sets can be really useful
  • Creating geometry takes a lot of time so I try to avoid that
  • Without knowing the inner workings of a custom node it’s hard to tell what’s faster. If you open a custom node and see a lot of OOTB nodes in it, there’s a good chance there might be a faster way to do it via a ZeroTouch or Python custom node. The same thing applies here: if the list that you put into the custom node gets iterated over a lot of times then it will probably be slow.

Hello all, I’m encoutering the same issues. In a script I extract a lot of parameter values from element out of a linked file. There are a lot of variables: Elements from different linked files, various inputs of different parameter names based on linked file etc.

On Large project it sometimes takes up to 12 hours to complete the script! And most of the times it still works! however I would like it to go faster…

Maybe you guys have some lumious idea’s?

try to do more stuff with codeblock or in a python script:
like replace the flatten node with:
or the list create node.
Less information lines are better.