Hi All,
I’ve been struggling with the transaction nodes for a while. I’ve found this article. is quite old but I think that the main focus might be still valid:
I’m trying to debug a big script for rebar creation, and came with the Idea that maybe it is taking too long to process all the data because of the transaction order?.
Well, I’m not familiar of how the transaction node works, so If someone please could explain me if my guess is right or wrong, I’d appreciate it a lot!.
Thanks in advance!
2 Likes
This is indeed old and no longer valid as far as I am aware. We would need a confirmation from the dev team on this.
Do you use manual transactions in your script?
Cheers!
Not yet, but I’m wondering I put some, it will help me to speed up my script.
Cheers
In general Revit these days wants to handle Transactions on its own, and even the External Commands recommendation is to not manage them manually (not exactly but for the sake of this conversation let’s leave it at that) but instead let Revit handle them. You only need to do this manually if you are creating things that later need to serve as hosts for other things since they need to be commited to the DB before you can use them downstream. What are you creating?
I’m creating rebars using Dynamo for Rebar node. The workflow is mainly: 1.- getting the rebar information from an excel sheet, 2.- do all the geometry creation 3.- transform the geometry into 3D elements.
From your explanation, I think that the transaction was just my hunch 
There are a lot of potential bottlenecks in this process. First reading large Excel files can significantly slow down Dynamo. The way it’s parsing excel files is REALLY inefficient. I am biased here since I wrote an excel package called Bumblebee that is a little faster, but even better would be some solution written around OpenXML implementation.
Another possible bottleneck is geometry creation itself. Dynamo spits out previews and whatnot, and that will slow the whole thing down to a grind. The best way to minimize that would be to actually never generate geometry in Dynamo context so that it doesn’t try to render it. If you were to create these objects in Python, then you could pass them downstream without having to preview/render them, and of course you can dispose of them. That would potentially speed things up a little bit.
Finally Revit itself is slow. Depending on what nodes you use to create the rebar instances, you might be able to gain some efficiency by using bulk family instance creators. I am not sure about the rebar nodes themselves, but i will take a wild guess they don’t take advantage of that functionality. I think the only ones that do that are the AC nodes.
Cheers!
2 Likes
@Konrad_K_Sobon, thanks a lot for the description. I’m now actually debugging the geometry creation and translating it into python nodes. Also, I’m measuring this process.
About the OpenXML implementation, the input file for the Dynamo Script is an excel sheet, Is it a way to translate all the data inside into an OpenXML environment?
Finally, the nodes for the rebar creation are the ones included in the Dynamo for Rebar and BIM4Struct packages. Do you know if they are using the bulk family instance creators?
Yeah OpenXML should be possible to implement for Word, Excel etc.
Actually i misspoke on that one. Rebars are not family instances, so no efficiency gain here. It only has that one method they are using, and that is as good as it will get. Granted they do some checks in that node to make sure new curves are not overlapping with old ones etc. but that’s all kind of needed unless you know you don’t need any of that. In that case you could save some time there.
1 Like