Multiple start nodes or single node?

Hello all,

Does any one know how dynamo deals with multiple first nodes (without an input)? As you can see below I have numbered the different start points in a graph I am developing. Is Dynamo able to use more than one core to start each of the tasks? (I am thinking no based on this topic) Is it quicker to pass smaller amounts of data to RAM or larger amounts? I am not sure how the back end works.

In section 9 I have one node collecting a lot of information then splitting it up for different sections of the graph. Is it more efficient to have one node do all the work or split it up into multiple?

If this has been discussed please let me know. I did not see anything though.

Thanks for your input,
Steven

I know there’s a post in here somewhere that talks about the best ways to optimize your graph but I can’t find it… :face_with_raised_eyebrow:

I think you answered your first question.

As for the second: the primary (only?) way to speed up computation is to essentially reduce the number of individual outputs. If you have a list of 1,000 items and make a single change to that list, your output is now a new list. You have two lists with 1,000 items each. Every function of your graph (that outputs a result) is adding to the number of objects that Dynamo must maintain. This can quickly blowup your memory usage when dealing with a lot of elements or complex functions. The general rule of thumb is Zero Touch > Python > Custom Node > Code Block > Nodes. It’s fairly easy to convert nodes to code block with Node to Code, so that may be a good start to speeding up your graph.

3 Likes

Thank Nick,

That does help a lot. I just finished running a test on time taken to complete code block in the image below. It took about 2 minutes to split the information up, so it should speed up the graph by dividing it up to start.

Quick question on Python being faster than custom node. If a custom node only has a python script in it would it be faster to take it out? All Elements of Built in Categories is a node I created so I could change the lacing. Since I am going to break up the information should I take it out since logiest lacing is no longer needed?

Answer to my question about node vs Python. Python is much much quicker.

Keep in mind that not all python is created equally. Nor are code blocks or custom nodes for that matter.

Geometry manipulation (via any method) is the slowest of the bunch so reduce that to the fastest way possible. One ‘point at parameter’ function with cross product and a {0,1} parameter target was faster than a curve.startpoint and a curve.endpoint function.

And remember if you’re running this once on the job (should be by the looks of it) then RAM isn’t as much of an issue as CPU, and simply removing the bulk (all?) of your nodes in favor of a single code block (or custom node, or python node), and running this via the player will likely produce the fastest result. Feel free to share what you have and we can help speed it along.

3 Likes

I am trying to gather a bunch of information about our Revit models so we can find issues before they become problems and gauge what teams are doing what. Its a health dash board or sorts. We are trying to find where things are going wrong in the office so we can figure out how to provide direct training. The bulk of this is coming from the code Ewan developed.

I am getting close to finishing it and hope my company will be ok with sharing it when done. Or shearing parts of it.
Right now It takes about 8 minutes to run which is not bad for the amount of information it is dealing with.

Thanks everyone for you help,
Steven

1 Like

That’s not bad at all for the volume of data you’re likely looking at. Have you tested on large and small jobs to see the discrepancy yet?

No I have not yet tested it on other projects just this one for now. I know I am selecting well over 100,000 elements (all families, walls, groups, lines, grids, level…). The project is 6 stories and about 75% CD. Its a great mid range project for testing. I hope that in the next week or two I can start to run it on many more.

Just restarted Revit and ran the script fresh and it took 4 minutes with the new optimizations.

what is likely slow here is marshaling all the outputs … to be a fair comparison make a function using the def keyword in the code block and only return the final result.

1 Like

in line code also functions the same right?

On this topic (and what I am thinking @jacob.small is saying in the comment above), does a code block with let’s say 10 lines of codes produce 10 outputs, even if only one output is used? Or are only the outputs being used actually maintained?

If it does produce all the outputs, then a definition is better, right?

1 Like

it produces all outputs and they are kept in memory so that they are valid for downstream nodes to use, a function definition should require less memory and require less marshaling of data between the DesignScript and .net VM (that last bit is more a guess, but I think this has to be done before we call toString() for the preview or pass the value to another zero touch node.

3 Likes

I have deconstructed the code block and made each section its own stream. This has defiantly sped up the script. As you can see in this new screenshot each stream is independent (I have not gathered the data yet for a single export). This allows the data to start when there is some free CPU rather than needing to wait for a bunch of other data to complete as well. Each stream took about 2.5 minutes to complete but the whole graph only took 4 minutes total.

image

2 Likes

the image is a little too small to see, but - If you are running in Revit -I am fairly certain we run the entire VM in a single threaded process.
@Aparajit_Pratap can confirm, but my intuition is that none of these branches are executing at the same time.

Sorry about the image. I would like to release a better one. I am working with my company to do so but as of now they own the work.

I would agree with you that each branch is being executed separately but in my latest run it took 3 minutes and 45 seconds to complete. (timed it on my phone) I have Clockworks Time.LapTime nodes at the start and end of each branch. The arrows in the image below point to the start and end of each branch’s timer. The numbers are how many seconds it took to execute that branch. At 225 seconds to complete the whole graph it would seam that more than one branch is running at the seem time. Unless I am miss understanding how the Time.LapTime node works.

1 Like