Do the Start and End transaction help with keeping graphs run more smoothly by separating out what each node needs to do? Or does it just make matters worse?
I end up creating some large graphs and try to minimize as much data required but most times I need so many checks towards the end of my graphs.
I will have graphs fail sometimes when trying to do too much. Wondering if Start and End Transaction would help the cause.
Example:
First part of Graph is gathering and grouping Elements as needed to organizing lists.
End/Start
Second Part would is gathering parameters, and running a series of bools against conditions.
Won’t help performance, as the model needs to calculate references at the end of each transaction. Will it be noticeably worse? Well I am not sure.
This wouldn’t be impacted at all as you didn’t add anything into Revit in the first part, nor in the second. Reading data (Revit > Dynamo) isn’t impacted by transactions and can occur without even opening a transaction. Writing data (Dynamo > Revit) requires a transaction to prevent concurrent write to the source file.
All thank you for the input! Understanding the Start and End Transaction does help me a bit, and give me ideas of how to proceed.
One of the graphs I am working on is adding Elements to Assemblies by BiMophs Element Intersects.
Towards the end of the could end up having 1000 Elements added to the multiple Assemblies. I think what maybe causing the Issue is that the 1000 Elements go through a series of Bool Checks to filter out by conditions. A wait-for node applied to the list of Assemblies to wait-for the its new Elements to be processed.
It is hard to tell because the graph crashes with nulls across the graph. When I break it down into sections everything works great, just when I put it all back together that’s when it likes to fail.
When I do simple single selects of Assemblies everything works great.
Organize the filters efficiently; do the largest set first, the second largest second, etc… It may be that this is better processed via C# or Python than multiple Dynamo nodes as with Dynamo nodes you process all the items then get all the items in two lists. Then you process all the items in one of the two lists again…
I like to think that it’s like splitting a dozen logs once and moving each of the 24 to a new pile, then splitting the 24 half’s and moving each of the 48 into another pile, then splitting the 48 quarters and moving each of the 96 eighths into a new pile. If instead you split the dozen logs into 8 pieces you could only have one new pile to make instead of three…
Jacob, I will try to filter out at the source of my Elements. I was trying approach of List.Join then doing a filter on bigger list as you suggested. I will try a different approach and see what I get.
If you know of way to get the parameter Assembly Name of an Element as opposed to GetParameterValueByName I would love to know?
GetParameterValueByName node seems to be a slug when you get into bigger Lists.
At a certain size any node will struggle with execution as too much stuff has to be maintained in memory. As a test try one point. Then a line of n points. Then a 2D grid of n^2 points points. Then a 3D grid of n^3 points. As you upscale n you eventually hit a point where your system just bogs down. You can do the same thing with multiplication… as the number of numbers (and to a lesser extent the complexity of the output list structure) grows things slow.
I recommend you install the TuneUp view extension for your Dynamo build, and tackle the ‘slow’ nodes (or sections of the graph) there.
Thank you for all the advice. Yes I do use TuneUp quite a bit and find where my slow points are in the graph.
I did successfully get my graph to run properly without issues. One of the things that I did is I broke up my filter closer to the source elements as opposed to one giant filter.
