Hello, I would like to know what tools and techniques to use in order to have the smallest and the most optimized Dynamo file possible? Does code blocks work faster and smoother comparing to nodes? What about python script? What are the things to avoid when creating a graph in order to have a “healthy” file?
I cant give you an answer about Codeblocks and speed of dynamo graph, because i simply dont know if this speeds up the graph performance.
But I started writing my graphs exclusevly in Codeblock, because graph becomes more structured. Also it is great, because you can start nesting different functions together.
Also check Leves and lacing, since it reduces nodes that you need in your graph.
i like to look at what person needs a graph and what the can read.
can the read code blocks or do the need nodes?
and i ask myself, if i would leave this company, can they still tweak my scripts?
I would say Python and the fewer nodes possible is best, however, I agree with @Marcel_Rijsmus, you should still make the graph editable to novice users. I usually wrap most my python in Custom nodes and they do a specific function (I try and avoid putting any python in the graph). Code blocks I generally don’t use as I prefer Python but they have their use, couldn’t say how performant they are though, maybe we can do some tests with the new Dynamo API tools for this.
Before you think about optimization you should understand what your script is doing and all the steps involved, because if it is working with text or numbers then any optimization will be negligible.
Though if you are working with geometry then it will be best to look at good practices on trimming the data down to what you need then getting it to run and re-use information without recreating it. This is because each OOTB node will display and re-run the geometric information for every node.
Eg you create a square rectangle of 1,000,000 points with no z value then you add a varied z value to each then generate a surface that you then grab points out from the surface for re-use in something else. This can cause memory issues and should really be done by add the random z value to the first generation of points that then create the surface. Do not generate points from the surface but re-use the original points.
If all of this is done i would then look at using Code block then look at python code. Though if you are using python you need to add in garbage collection into the python code to dispose of geometric information that is not part of the output.
in master (2.5) daily builds we do this automatically now, of course you can still dispose manually for full control. This change still needs continued testing, but I wanted to mention it.
- zero touch will give you the best performance
- don’t return geometry or items which are tessellated into the graph
- don’t return extremely large lists that need to be displayed in the preview bubble
- don’t expand entire csvs or excel files - stream them using a stream reader
- check out https://github.com/DynamoDS/TuneUp - though it will only work in master currently, and is still very much a WIP.
sorry, I may have mis-read the question, are you concerned about performance or file size?
I would add to be sure to remove unnecessary element binding, but I feel like I a broken record in doing so.
Seriously though, make sure the stuff in your ‘all projects’ and ‘Dynamo player’ libraries have no bindings in them.
Thank you all for very useful tips! Definitely a lot to keep in mind in the future.
@Michael_Kirschner2 , I was concerned about both the performance and file size, and I am sure there is a strong connection between those two. I am also
very excited to hear about https://github.com/DynamoDS/TuneUp project. I think it will be a very powerful tool to monitor the performance of the graph, and will affect the way users build their graphs in the future.
If your file size of dynamo is getting over between 100-200KB then i would suggest you are creating/using revit elements within and therefore dynamo is probably doing “Element Binding” which @JacobSmall has a post somewhere about this subject.
Any file size less i wouldnt even bother worrying about them, and only be concerned about the time frame from run to completion.
Also if you are wanting to stop “Element Binding” then you need to set the file to read only prior to it being opened/run or do not save after it has been run. Though this can break some of the benefits of why this was introduced!
This MIT open courseware lecture has a great explanation on some strategies for reducing computational complexity (and therefore runtime). Worth watching the whole thing (the entire lecture series) if you’re into this stuff.
Where’s Jacob’s post? I don’t even know what Element Binding is… how can I remove them if I don’t know what they are? Oh the insanity of it all!
This is the post Element Binding in Revit
That’s crazy! Thanks Jacob…
Now to make a graph to clean my graphs! LOL