When I start a graph for the first time it takes about 45-50 seconds when my graph is executed. Dynamo is NOT started. I have 5 packages installed but the graph uses no packages when executed.
This is way to slow.
What I think is… it loads Dynamo (and all packages?) in the background and starts the graph. How can i speed up this process?
(when I start the graph for the second time it starts faster)
I use only pyRevit to create a button to start the graph, but the graph is pure Dynamo. I don’t want use Dynamo Player.
How long does the graph take to run if you run it after dynamo has already been loaded?
Why start up is a little slow is because revit is opening and loading dynamo into memory which will always take time. This cannot be changed and is a must happen element.
If you are not happy with this speed the next best thing is to transfer your script into a native revit addin and this will decrease run times.
To leverage code you have to pull all the references you’re going to use into one environment before you can execute them in.
Let’s say you were to run your graph in Dynamo. This means you have to launch Dynamo by clicking that button, let the computer load everything into your environment (all your packages and such), then you can open the graph hit run and it can go.
The same holds true for Dynamo Player, but with many of the references which Dynamo uses removed as you don’t need to see anything. This is often referred to as headless, and is run via a command line interface or CLI. Since it is headless everything about the environment that only relates to what we see need not be loaded. As a result stuff to display geometry, the node library, node search tools, all your view extensions are left behind. That removal of environment stuff means things go a good bit faster - but you also have to load up the UI for player which is another bit of lag in the process to start what is really a web browser for the UI. You can then use that UI to execute any graphs you might like, and progress from there with the main instance staying open between runs. Occasionally that instance will be shut down for stability reasons (often when changing graphs), but the idea is to leave it up.
Now let’s talk about running via PyRevit. I am not involved with PyRevit development and haven’t looked at how people are managing it for awhile now. But last I did the process there is similar; you click a button and PyRevit opens the same headless instance of Dynamo that Dynamo player starts, loads up the environment that you have less everything associated to display stuff, opens the graph and runs it. It may or may not leave that instance open permanently, or until you change graphs, or otherwise alter stuff. The only ‘speed’ difference will likely be that you don’t have to load the web browser to get to the graphs you execute. Instead you pay that penalty when you start Revit, as anything that isn’t ‘built on demand’ such as the Dynamo and Dynamo Player UI are built when you startup Revit. So there is some time savings if you use that toolbar every time you launch Revit, but if it’s 50% of the time you’re likely getting the same result. The same ‘startup hit’ is included in Python scripts too - all of those loads into the Python environment add up if you aren’t careful.
Now let’s talk about a full non-Dynamo add-in. This is the most difficult to build, but fastest executing. However that speed can once again be a trade off to starting Revit. If you took every Dynamo node to create an element in Revit and converted it to it’s own add-in the startup time for Revit would be atrocious. All of those tools have to load in individually after all. Some of this can be mitigated by using common libraries already brought in with Revit, but you’re assembling the environment either way which is slow.
So what is the ‘fastest’ way? Well likely a full add-in that does ALL THD THINGS you want it to, no Dynamo or PyRevit involved. But the time to build and maintain that is pretty significant. The fastest way to build is likely Dynamo, and Player is likely the happy medium. PyRevit in my opinion is best suited for full Python execution with no Dynamo involvement, but at that point a full add-in isn’t too much more work for the initial build, and owning the full tech stack makes maintenance quite a bit easier.
Thanks Jacob.
I’m no programmer that can build an add-in, or fully programming a Python-script. Sometimes it’s hard to understand your explaination, but Google Translate is my best friend. . I’m from the Netherlands.
So if I decide continuing using pyRevit there are no options/settings available to speedup executing my graph?
The packages are in a networkfolder (company). It is not on the internet.
Several users are using this so I want do place them at one place for maintenance, not on a local disc.
This is going to be slow and also makes searching nodes not so fun due to how MS networking works, and is a bit of a security risk as you’re enabling executing code on your computer from a spot not on the system which makes compromising everyone’s system pretty easy as I understand it.
I recommend you have your IT staff setup some tooling to copy the office packages to the relevant Dynamo packages path on each user’s appdata folder on login, upon starting Revit, or on demand.
I’ve placed the packages on a network folder.
I have tried also the local user folder of Onedrive, but is has the same problem.
I really don’t know why it takes so long when starting it for the first time.
Is this a bug or should I ask AutoDesk?
Should it go faster if I use less Dynamo-packages?
Edit: all folders (including Revit) are in a Citrix-environment.
Not a bug and nothing my colleagues can do about it as it has to do with Windows and Microsoft’s networking protocol; they aren’t going to change either of those tools to speed up your startup and IT professionals will advise you move the packages to the local disc.
Copy the files to the user’s %appdata% folder related to their Dynamo instance to speed things up.
. I’m from the Netherlands.