I would like to view the results of a Dynamo program with different parameters, but there is a problem with the execution time: only the second execution takes an unusually long time.
If you know the cause and solution, please let me know.
[Situation]
The following is a detailed explanation of how much slower it gets.
・The first time I start Dynamo Sandbox, it takes 70 seconds to execute the Dynamo file.
・When I rewrite one of the parameters at the end of the program and execute it again, it takes almost 10 minutes for the process that should be done within 1 or 2 seconds, as I imagine from the result of measuring the time required for each node.
・When I rewrite the parameters of the same place as before and run it again, it finishes within 1 or 2 seconds this time as expected.
In short, only the second run takes an unusually long time, and the third and subsequent runs finish within the expected time.
So far I’ve dealt with this by starting up a new Dynamo Sandbox each time to get results with different parameters, but I’m finding it inconvenient.
Please let me know if you know the cause of this problem and what I should try to solve it.
Thank you very much.
Sounds like a memory leak of some sorts. There’s a package called TuneUp that lets you monitor the amount of time (in ms) per node. Also, have taskmanager open and see if there’s enough RAM free to work with.
After running the script, you can click on a node in TuneUp to see which nodes takes more time than usual.
Can you share your script here so other people can reproduce?
I’m going to study “Element Binding in Revit” that you gave me.
This is new knowledge for me! Thank you very much.
Am I correct in understanding that the occurrence of improper “Element Binding” is one of the possible causes of the problems related to the computation runtime that I am experiencing?
I’ll share additional information below.
I’d really like to share the Dynamo file with you to share the problem,
but I can’t send it to you right away because it contains confidential information of our customer.
I am trying to reproduce the problem by using dummy data. It will take about a week.
In the meantime, I’ll share my research on the execution time in more detail instead.
We used PythonScript to place timestamps on the nodes that are not affected by parameter changes and on the nodes that are affected by parameter changes in the second half of the calculation. We expect that the stamps in the first half, which are not affected by the parameter change, will not be updated and only the stamps in the second half will be updated.
→However, only the second time, both the first and second halves were updated, contrary to our expectation.
As for the memory occupancy, it was about 2GB at the end of the first run, but it increased to about 6.5GB at the end of the second run. This value peaked at the end of the second run, and declined with every third, fourth, etc. run, until it finally reached about 3.5GB.
Last but not least, the environment used is as follows
・Dynamo SandBox ver2.9.0 (standalone type)
・Processor Intel(R) Core™ i7-9700 CPU @ 3.00GHz 3.00 GHz
・Installed RAM 32.0 GB (31.8 GB usable)
If you’re in sandbox and not Revit than there isn’t any element binding in play. Which nodes are slow when you utilize the tuneup view extension on the graph?
No one can know for sure until you share a graph, but my guess is it’s more likely related to the size of the data set, or rendering the preview (geometry or data). Try converting any large lists into dictionaries and see if that resolves the issue. There are also significant performance gains in newer builds - upgrading to 2.10 or even 2.12 may resolve the issue to some extent (and since you’ve got no involvement with Civil 3D, Revit, or any other host you can update the version without any limit on the tech stack).
Thank you for always politely teaching me
I’m sorry for this reason, but it’s taking some time to try the answers you received.
I’ll try it by tomorrow, please wait a moment