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
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
The ask:
For Dynamo graphs and Revit projects posted here (Publicly) or send to us via DM (Privately) that we can run and profile 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
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.
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.
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 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.
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
We have other work at play to improve the speed of building Graphs 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
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
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.
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.
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.
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)
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?