[Request for Feedback] DynamoRevit Performance

Are you a Revit user? Do you work with zippy and fast graphs in some cases, but incredibly slow ones in others? Do you happen to know how and when that slowness manifests? Are you willing to share some of these cases with us?

Then we want you! We are about to embark on a profiling report of DynamoRevit that will enable us to better understand where slowness resides, and where to best put our efforts to resolve it. To be successful at this, we are looking for help from those closest to the problem space… you :star_struck:

Now, the answer may be inside Dynamo’s Engine (VM) which is a hard problem, or inside the single-threaded nature of Revit, also a hard problem, which we know of and have longer-term plans to resolve. But, the answer could very well be in a bunch of decisions made in the past that didn’t stand the test of time, or were not validated as they should have been, and the best way to get to the heart of this is with workflows from real-world projects that aren’t quite up to snuff.

The goal:
Understanding how we can create a much more performant, robust and effective DynamoRevit for you, dear customer :pray:

The ask:
For Dynamo graphs and Revit projects posted here (Publicly) or send to us via DM (Privately) that we can run and profile :clock1: in order to hierarchically rank the most fruitful places for us to put development effort into improving the performance of Dynamo inside Revit.

If you have graphs that you know should run fast in theory, but don’t, then we want to hear from you! If you have graphs that work well in small cases, but fail on a bigger (But reasonable) set of data, then hit us up! If you have workflows that run well when you freeze half the graph, unfreeze then run again, but sit in an endless loop when you try to run the whole thing then you are exactly who we are seeking!

Please help us to help you - we’re in this together :muscle:

7 Likes

Efficiency from external packages (Dynamo or Python) could have significant impact here in some cases. How close to “out of the box” are you wanting and/or expecting these graphs to be?

There are some workflows where we heavily rely on external packages for better performance than the core Dynamo/Revit functionality can provide. This often works to an extent, but there are times when it feels like Dynamo is still a limiting factor. Obviously, it’s not Autodesk’s responsibility to fix or even troubleshoot any potential performance issues with the packages themselves, but I’m curious how much (if at all) this exercise will be looking at the interaction between custom packages and their operation within the Dynamo environment.

2 Likes

Not sure if it’s completely related to the post but too many times I see someone complain that Dynamo is slow, only to find that the issue is that they’ve pointed their package location to a shared location.
I think a simple warning or tooltip when a user assigns a package location could prevent a lot.of frustration in new users.

1 Like

In some cases it’s the opposite - We had one case where working with IFC and 54k elements, where it took around 3 seconds using a Collector looking for an IFCGuid parameter, and 31 seconds using the Element.GetParameterByName node. These kind of cases we can look at improving as theoretically, as you mentioned, Python should be slower given the environmental data transfer.

If you know of external packages that function much better than out-of-the-box alternatives, then please do put them into this thread :slight_smile: We very much want to know, especially in bad scaling scenarios where the base node is good in a simple case but not good at scale.

2 Likes

Is this about the speed of execution of a graph or the speed of when we build graphs?

Because I think whether a graph runs 5 seconds faster or not is not important because you get hours time saved usually…

if anything I would want a faster bootup time when opening either DynamoRevit or DynamoPlayer and opening the graph.
Dynamo player to be able to handle subfolders etc

And yeah a lot of times when you put Lacing to cross, it’s your own damn fault the script runs for 10+ minutes haha

2 Likes

We have other work at play to improve the speed of building Graphs :slight_smile: Node Autocomplete powered my ML as one piece, and some AI efforts to come around General Python help and Lay-person warning assistance.

Faster boot time we are also looking at as part of the Dynamo-as-a-Service effort, so expect some gains there too :muscle:

So all of the above? :smiley:

Renaming views is annoying as it can encounter an error for double names.
Same with Grids.

So you need to rename views something with extra string, then remove the extra string and set the name again. You might look into that…

Detailbladen hernummering_2.dyn (132.5 KB)
01.1_AUTO_Gridlines.Hernummeren_script.dyn (125.7 KB)

This is intended behaviour though, as a name already exists and Revit itself (thankfully) doesn’t allow for duplicate view names. I feel if it were changed how this works in Dynamo would result in unexpected behavior. What happens to the existing(duplicate) name? Does the view get deleted? Does it get renamed? Somehow you will have to make space for your renaming logic, a fast approach imo is to just first rename all views in the list with ‘temp’ as suffix, so all names are freed up. And follow that up with the desired renaming logic.

In my opinion the dynamo user has to handle the issue of the existing names, just like a user in Revit would do manually. Letting the set param node decide what needs to happen with the existing names will get confusing

2 Likes

Then generate a prompt that the script will make duplicate names. They asked for faster processing, this is an avenue where a node could be improved. Why not just add an optional input for a string of temporary suffixes?

This would actually slow stuff down. By a lot. And reduce the value of DaaS as you’d have to pass the input to the server, then trigger a UI (if we can even do that) for the local user to provide the input.

Sadly the duplicate name issue will impact speed no matter what (unless you remove the issue by using “NameOnSheet” or a parameter which can have duplicate values) as the values have to update in Revit, and then the Revit parameter manager has to Review the data and then update the value anew. Any time there is ‘data validation’ against the larger model’s dataset (anything which throws a warning or requires additional action such as view names) you are taking a speed hit in favor of ensuring data quality (something which Revit won’t remove). The other reason view renaming is slow is the number of cross references which have to update; Remember that views have their own workset and editing worksets is a VERY time consuming action to prevent data corruption (you don’t want to wind up with an element on View 1 thinking it’s on View 2. Well not if you want to keep working in that model anyway…).

Fortunately the Revit team has that code pretty well optimized, and DaaS will make the pain of this go away so an extra 60 seconds to set ALL names to a unique random value and then set the names to what you want them to be on a VERY large set of names (say 1000 sheets) should make things pretty quick.

1 Like

Issue 1:It would become very slow if installed for too many packages.
I try to use OOTB nodes as much as possible.

Issue 2:Zoom in and out lags when there are too many nodes in the graph.I think the node name is the cause of this?Here’s the video.Actually there’s not that much nodes compare to grasshopper and it zooms smoothly there.

Issue 3:If dynamo opens for a revit file and then I want to create a family.Even if the mode is manual.It will become very slow when I click different view of family.So I have to close dynamo and after I have created the family and load into project.Then I’ll have to reopen the dynamo and re run to continue my dynamo script modification.

3 Likes

Well if you’re looking into that avenue. I’ve noticed that Dynamo’s node searching function stops working after opening and closing DynamoRevit in succession (When testing and preventing element binding).
The Dynamo node searching is slow to begin with and for some reason I can only use backspace when writing in it because when I press delete it will also delete the selected node.

@jacob.small DaaS?

Another script I have takes a while to load too, but should be quick. Since I put scripts behind a pyRevit hosted toolbar button I want to put extra emphasis on Dynamo bootup times
Huidigedetails in Section 3D_script.dyn (63.1 KB)

1 Like

DaaS = Dynamo as a Service - THis is indicated on the roadmap under the in progress section.

1 Like

Dynamo as a Service. AKA what if you could run your graphs on the cloud instead of locally.

I still feel that the way PyRevit is handling the Dynamo instances that run your graphs is impacting that - have you checked with that team or explored their source code?

1 Like

No as I am a BIM engineer, not a software engineer

Curiosity is the wick in the candle of learning. :wink:

1 Like

And yet you’re developing code… Curious, but my guess is you’re in for a pay raise!