How to improve my dynamo script speed

Revit
#1

Hi there,

After being inspired by @JacobSmall on his recent visit to our offices in Hong Kong, I’ve written a few scripts, however my latest one is taking a long time to run. Since I’m still quite new to Dynamo, I suspect that there are shortcuts/improvements to what I am doing, however I’m not sure where they might be.

I am collecting up to 10,000 revit family location points, converting them to survey coordinates, drawing vertical lines from each to find intersections with 3 layers of topography, then extracting the Z coordinates of those intersections, which are then fed back to the revit file to update the levels of the families. I am also exporting to excel this data, but turning this off in tests has not made much difference.

I have been testing this on up to 20 location points and it takes 12 minutes, but with 10,000 to do, that’s a lot of time.

what is taking the time… is it the extracting and returning of the revit family parameters…? (see extract of the script below)

any ideas…?

Nick.

btw, I cannot yet upload my dynamo script as I am a new user, but I’m happy to share if this becomes possible later.

Capture
Capture.PNG1617×800 92.7 KB

#2

Side topic, when did @JacobSmall come to Hong Kong???

2 Likes
#3

I was there for a bit more than a week doing a targeted training with a few users back in early September.

@nicholas.andrew good to hear from you! Hope all is well.

Any chance you can you upload to a third party sharing site such as onedrive, google drive, box, etc?

It looks like you can replace those nodes shown with two Element.SetParameterValueByName nodes, making use of lists, lacing and levels will be important though. Think about the elephant, fish and colors example I gave in the second lunch presentation. Reworking those to take advantage of list processing will save some time and reduce the the amount of Ram used.

However, my guess is the time isn’t from this though, but from either the geometry operations or perhaps the element binding. Try doing some node to code work on the geometry efforts and build a single inline statement for that bit.

I’m in another conference today (at my office in Boston) but I’ll review and help out if you get the files posted.

#4

Reading up more after I posted, I came across a comment about lacing the parameters. I’ll give that a go tomorrow and see how it goes… I think I can post files now, so I’ll do that after I’ve played around tomorrow.

Thanks for the hints @JacobSmall :grinning::+1:

#5

Another nice and easy thing to try is wrapping some of the larger processes in a custom node, I’ve experiencing a significant boost in speed :slight_smile:

3 Likes
#6

I think that the slowest task is the intersection of geometry.

Which node do you use for that?

#7

The underlying topography mesh faces could be too complex.
Try simplifying your meshes prior to running intersections.

I encountered similar performance issues when extending pile geometries to bedrock topographies created from a contour file. I couldn’t find a stable method for simplifying the meshes natively in Dynamo so I punted to Rhino, then brought a simplified mesh into revit so Dynamo could do its thing.

In my case the native topography from a contour lines import was 900,000+ faces.
For my needs I could simplify this to just “Over 9000” and Dynamo was much happier with that.

#8

so I’ve taken your suggestions and hints and updated the script. At the moment, it doesn’t make a lot of difference by:

  • Simplifying meshes in revit (~5% difference)
  • setting parameter values in one node
  • calculating the survey point coordinates by translating the final point geometry rather than the full project geometry

The comment above regarding the geometry intersect being the time consuming aspect is now looking like it might be the case. I’m drawing vertical lines from each point and finding the geometry.intersectall against each of the topo files.

I’ve included the dynamo file below, and many thanks for the help already, and any future help is also greatly appreciated.

Nick.

Home.dyn (136.0 KB)

#9

I’ve wondered this for a while. If you were to do a Element.Geometry node and intersection node in a custom node but not output either of them, would it still slow down everything after as if they were part of the full graph or does it save a lot of memory?

#10

It will save on memory if they are done in one in line function (either by design script or code block). Not sure how much, though I may test it later.

1 Like
#11

Would defining a function in a code block that uses geometry and intersection do the same thing? Then where you need it, calling the function in another code block.

#12

Not sure but I believe so. I’ll add it to the test.

1 Like
#13

Adding my 2cts:
I just noticed that using List.GetItemAtIndex both as as an OOTB node or as designscript on something liek 100k points crashed my dynamo, but writing the code in python (fetching item with the [ ] brackets and appending them to lists) worked like a charm in under a second.

#14

when you use a dynamo node to do this you are creating a second geometry entity in the graph which will be rendered, this has the additional cost of a second tessellation.

Do you mean that you returned 100,000 items from the list.GetItem function, or that you just returned a single item out of a list of 100,000?

1 Like