Speed of Dynamo

Developers
1

I created a Dynamo to add the itemnumber property in fabricationpart ducts. its working perfectly in trial but when i apply in real project its consuming more than 8 hours which i need only 8 hours if i do manually. is there any way to increase the speed of dynamo ? please adviseAdd Item Number to typical ducts.dyn (21.5 KB)

2

Upgrading to Dynamo 2 might help as a first glance.

You appear to have multiple Python nodes in sequence, and are iterating over every item against every item in multiple instances too. Reducing to one node with one loop would likely help.

Some screenshots showing the scope of your project might also ID the cause.

Also I challenge the idea that It could do this myself in 8 hours’ as that 8 hours will be 100% complete so you don’t have to worry about ‘did we catch all the parts’, and it can run on CPU 2 while you work on something else.

1 Like
3

thank you for you response. Can you please explain little more about “Reducing to one node with one loop would likely help.”

I am in learning process.

4

How many python nodes do you have which write data out to the Dynamo environment, only to bring it back into the python environment? Do that only once.

5

@shibujoseukken

Jacob is right, when you are inside a python node, based from experience as much as possible, finish the whole script in it. Also, when your script is still slow, try to create a custom Dynamo node using Zero Touch (C# programming language), sometimes it lessens my runtime to as much as 1/10.

-Biboy

6

@shibujoseukken

avoid multiple nested loops, here is an example of reasoning with a dictionary

import clr
import math
import System

clr.AddReference('RevitServices')
clr.AddReference('RevitAPI')
clr.AddReference('RevitAPIUI')
clr.AddReference('RevitNodes')
from  Autodesk.Revit.UI import *
from  Autodesk.Revit.DB import *
import Revit
clr.ImportExtensions(Revit.Elements)
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager
doc = DocumentManager.Instance.CurrentDBDocument

from System.Collections.Generic import Dictionary

level = UnwrapElement(IN[0])
ItemNo = IN[1]

myDict = {}

levelFilter = ElementLevelFilter(level.Id)
elmts = FilteredElementCollector(doc).OfCategory(BuiltInCategory.OST_FabricationDuctwork).WherePasses(levelFilter).WhereElementIsNotElementType()

TransactionManager.Instance.EnsureInTransaction(doc)

for i in elmts:
	sizeStr = i.Size
	prCode = i.ProductCode
	paralength = i.get_Parameter(BuiltInParameter.FABRICATION_PART_LENGTH)
	length = paralength.AsDouble() if paralength is not None else 0.00
	lengthStr = str(round(length, 3))
	mykey = prCode + '_'+ sizeStr  + '_' + lengthStr
	if mykey in myDict:
		i.LookupParameter("Item Number").Set(myDict.get(mykey))
	else:	
		myDict[mykey] = str(ItemNo)
		i.LookupParameter("Item Number").Set(myDict.get(mykey))
		ItemNo += 1
	
TransactionManager.Instance.TransactionTaskDone()	
iDict = Dictionary[str, str](myDict)

OUT = iDict

Note: 8 hours still seems a lot, even for poorly optimized code

1 Like
7

My guess is that this both an exaggeration and a question of scale. It wouldn’t shock me to see this run on a scary big number (10^8?), and since they are fabrication parts anything around automation with them becomes a convoluted effort due to the way they are implemented (data pulled from an external database in many cases).