Hi guys,
my dynamo is running significantly slower and slower with every run I did some searching at forum, but none of the advices worked. I noticed that with every run I’m getting more and more rows of “Flags cache is null …” in console (picture for reference). Could it cause the slowdown for each run?
Can I fix the Flag feature somehow? (we have strict firewall rules, I somehow expect it has something to do with.)
Might be related, but more likely related to something else.
What context are you running this in?
Can you post logs and journals (if hosted by Revit) from a slowing session?
DynSlowingSession.7z (243.2 KB)
I’m using Revit 2024 with Dynamo 2.17, but it started for me with Revit 2023.1 in combination with Dynamo 2.16, or maybe with some windows update. But context should not matter, it’s happening also in the sandbox version.
I’m on windows 10 with little bit overshooted specs (i9, 128Gb) so it should not be hardware related.
I did some python experimenting on my PC, but it’s happening also on other PC’s in company where it’s practicaly fresh install. So I would expect that should not be the cause.
It’s weird, cause I can see generated results but I have to wait for dynamo to finish for longer and longer time after the results. Also when it happens, the saving time of script gets painfuly long.
I’m on mobile and can’t open the 7z just yet, but if it reproduces in sandbox then one of those logs would be the best place to start. Also a listing of what packages you have installed (screenshot of the manage packages dialog works) and the paths you are loading them from (again, screenshot works) would help narrow stuff down.
Paths are default. With only the .dyn being loaded from local network.
I did try it with no custom packages and the slow down still occured.
Shift the dyn to a local drive and see if that fixes anything. Often ‘slow to save’ is a function of a network protocol resulting from infosec policies, none of which the dev team can reasonably be expected to test/maintain.
Unfortunately it haven’t helped. When I run 3 times the script and save it to desktop. It takes 1min 40sec, when I save it again with no changes to script and no runs it takes 2 mins. By the way it also affects placing nodes in the workspace, but kinda wierdly:
Can you post a single Dynamo sandbox log from such a session? Or is there one in that zip?
In the .zip there is only revit and dynamo+revit log.
Sending “short” video of behaviour. (have to speed it up 4 times to get it in size limit)
And Sandbox Log in next post
Sandbox log from the video session.
Ok this is really weird… I don’t see any immediate issues though. Flagged with development to get them to have a look.
Thank you.
I did try few more things whithout effect:
I got a hint. The rate of slow down is dependent at ImportFromSatWithUnits / ImportFromSat (both versions old and new) node, when I take just one nurbs curve from SAT it’s still slowing down but at much slover rate than as discused yesterday when I was importing about 20 of them. I’m using the SAT as transfer format between PC with Revit 2024 where MeshToolkit doesn’t work and other PC where it works.
For the moment I’m trying to switch exporting curves as CSV and then recreating. It seems that this is not slowing the dynamo so much but the “Feature flags cache…” is still spamming the log file.
Ok - that points to a lack of RAM or other system resources.
Based on what you’re describing, it seems that utilizing either the Data.Remember node to serialize the data into the .dyn, or the SolidDef nodes might be a quicker path forward than rebuilding curves.
The data.Remember nodes are pretty straight forward from a use standpoint: Open the graph in Dynamo for Revit 2024, gather what you need into a Data.Remember node, disconnect the input to the Data.Remember node, save the graph, and open the graph in Dynamo for Revit 2023 (or another Dynamo application entirely, such as Dynamo for Civil 3D).
The solid definitions are similar in that they’ll push the data to a text format, but they are closer to native Dynamo language. This example shows how they work:
Process is open Dynamo for Revit 2024, write out the geometry to a text file. Then ion the other computer open Dynamo for Revit 2023 and read in the geometry. Note that you can combine this geometry string with other data as a JSON and read/write that as well - entire parameter sets, element IDs, and other content can go in with the geometry. I frequently use this in my work for generative design appliactions.
We’ll still track the slowdown cause, but for now this may be a viable path forward, and likely simpler than rebuilding geometry via CSV.
Thanks for the options.
SolidDef seems to work like CSV. It’s not slowing dynamo so fast, but the issue is still there and it’s significant to my previous experience with dynamo.
There should not be resource problem, my specs:
Bit weaker GPU, but I did try to turn of background preview. Problem persists.
That RAM isn’t all available for Dynamo though. A lot of it is needed by Revit - 20x the size of the file and all linked documents. So if you are opening a file which is 1gb, Revit wants 20gb of RAM available. 1GB with 2gB of links? 22GB (though sometimes this will require 60… it’s quite a variable calculation actually)… Opening 1GB file and then a 1GB file? 40GB.
Also Windows and everything else on your CPU requires RAM, and depending on how things are configured Revit might be capped at say 16GB and Dynamo for Revit can only borrow from that pool if memory serves. This is one of the reasons I advocate for sandbox focused workflows when possible.
Reducing the number of trips to the well, simplifying data collection, and reducing node counts can also help.
But all of that is hypothetical and/or best practice - for the performance of a graph it’s likely best to start a new thread outlining your workflow (also please why you need the workflow reviewed so we can highlight the impact of the mesh issue) and providing a base data set for people to try and build a solution around. It may be that accessing the mesh in the context of the Revit API and circumventing the mesh toolkit entirely is the most optimal path.
All of that said something else is off, so we’ll wait for me of the dev team members to look things over. Hopefully they’ll be able to review and perhaps come up with a good fix.
I’m running at 30% of RAM when inside my current revit project (which takes only around 3GB of RAM). I have nearly all the time Task Manager up to watch for resources and even looked into Procceses detail if there isn’t sth interfering with dynamo. But that’s not the case (as seen by my eyes).
For more complex geometry I usually use sandbox, especialy for EVO and DynaShape packages, to use as much resources as I can. And it worked briliantly in the past. But this issue with slowing down is new and is not dependent on context … slows down in revit at same rate as in sandbox.
I would understand that it can be my mistake in script structure. But then it would not make the script slow when saving it and when placing nodes from library, am I right? Or is dynamo saving some progress data inside .dyn file and that floods the .dyn file? (still would not be reason to slow down placing nodes from library…).
I have a lot of dynamo versions on PC:
Sandbox 2.10; 2.12; 2.14; 2.15; 2.17
RevitCore 1.3; 2.0; 2.3; 2.5 2.12; 2.13; 2.16; 2.17
Could that cause some trouble?
Good way of putting it, yes. Eventually you’re loading more data into nodes then you have RAM, and so the flood generates. using dictionaries instead of lists, nested functions in design script, managing your memory in Python (dispose method) or custom nodes is a good fix for this.
A quick note: Task manager won’t report RAM usage in Revit correctly, as it’s smart enough to start page faulting (using HDD instead of RAM) before it needs to (which makes page faulting quicker). Best to look into the file size I noted above instead.
Three devs weighed in on the log… one theory is that something is off with how your Dynamo is configured, which is perhaps being compounded by some network restrictions. Hopefully we’ll have more for you tomorrow or later today after they do some more digging.
Development has asked if you can get these IPs though the firewall: Public IP list
Added the IPs to the firewall, but with no change.
Feature flag cache still spamming log. (would expect that at least this would disappear after whitelisting the IPs)
Dynamo gets slow after few runs of script.
