I’m debugging a big script (rebar creation script). For time measurement I use the Clockworks’ Time.LasTime and Time.EvaluateLapTime nodes. I’m measuring portions of the script to debug from the slowest to fastest.
I don’t know if I’m messing it up somehow, but the parts measurements don’t relate with the total time. For the different parts (which are around 10) I have measurements that indicates each section takes 0.5 - 3 second to pass, but the whole script takes around 2 minutes.
Is there a process behind that open and close the transaction that it is slowing down the whole script? (This is just my guess)
What patch should I take? What do you do for measuring time?
Hi @Jorge_Villarroel I used a diagnostics version of the nodes which output a timespan from .NET’s Stopwatch class. For timing the OOTB nodes…it hacked a similar workflow to what you have using ZeroTouch versions of the same class, but it was temperamental and thrown together to complete my bench marking tests - not something I would want to release and inflict on others!
To simplify your existing workflow, you could try and get the Time.Lap nodes to simply start but not stop and configure it in such a way that the first starts with the first input to the node you want to time, and the second receives the output from the test node as an input to trigger the start of its timer. Then its a simple case of stopping both and deducting the two time spans to yield the total time elapsed.
If you’re concerned about transactions try adding a Transaction.End node at the end of each block that modifies the model before passing your data on to the next Time.LapTime node.
Thanks @Andreas_Dieckmann. One thing that I don’t really get is the “RerunToggle” input. If it is set to True sometimes it gets me different measurements? Do I have to let it always in false?
Also, if I don’t want to use it in sequence, they don’t work? In some cases I want to just measure for example a python node that has a big process, so, how would you recommend to use it for this particular case?
By the way, in other thread @Kulkul gave a suggestion for measuring time in python nodes:
but I would like to know how can I do it with your nodes, because I think they are a great tool!
The rerun toggle is for forcing any LapTime node to re-measure time, e.g. when you’re re-running a graph. Otherwise a LapTime node will only take a new measurement if its passthrough or the upstream laptimes have changed. So basically if you’re running a graph for the first time set your rerun toggle to True, on the next run set it to False, on the next to True again and so on.
You don’t need to use the nodes in sequence if you just want to measure the execution time of a portion of your graph. Usually, I’m interested in the entire run time, though, that’s why the nodes are designed with the ability to be chained.
For multiple measurements inside Python nodes you could just use the same techniques used in the TimeLap node inside the Python node - or alternatively divide the Python script into multiple nodes and use the LapTime nodes between them.
It is seconds, precisely the number of seconds since January 1st of the current year. You need to subtract the measured times from each other to get the delta.
You also have to remember that these nodes can only measure the the time on dynamo’s side of the workflow. Once the graph data has been processed by the nodes and passed over to Revit, from the POV of Dynamo, its execution is complete and it’s of no concern to the graph that Revit is churning away through a transaction.
To get the entire execution time (graph time + transaction time), you’ll most likely have to use some form of verification at the very end of the script (i.e. read the new value of a changed parameters or some property of a newly created element and return it to the graph) because Revit will only be able respond to that request post factum.
Hi @Dimitar_Venkov, the point that you mentioned is very important for my workflow, because I’m creating Rebars. When I run my script, I look in Revit that after just a couple of seconds, the rebars are created but the “still working” circle of the pointer is still running. From this, I assume the whole process is not finished and is at this point, where the most time is spent (I think this is the transaction time, right?)
