Performance difference between Dynamo vs Revit API

[MehtaRajesh]

Hi,

Understand the performance difference between Dynamo vs Revit API.

We have developed dynamo workflow to ..

(1) Pile structures having lakh's numbers
(2) Get the Bottom value of pile
(3) Overlayed on Surface (Generated From Contours)
(4) Get the new Bottom point
(5) Updated the Bottom and Top point for Piles

It is taking hours to process.

If I develop application using Revit API in C# for same kind of working. Will it take less amount of  time compared to Dynamo?

If anybody in this forum has compared two versions, please provide your valuable inputs here.

Is the way internally Dynamo and Revit API works in a same way?

Regards
Rajesh

[jeremytammik · Accepted solution]

Dear Rajesh,

Thank you for your query.

The Revit API is a .NET API.

All access to it is via .NET.

Dynamo accesses the normal Revit .NET API via .NET, so it will definitely never be faster than a non-dynamo Revit API add-in.

Therefore: Yes, definitely Dynamo and the Revit API work in a same way internally.

There is not that much overhead being added either, so Dynamo should also not be very much slower.

If your process requires hours to complete, there are to possible causes:

1. That is the amount of time that Revit requires to complete the task.
2. You have implemented some very inefficient algorithm.

Re 1: In the case of 1, there is not much you can do about it.

You could (and should!) however run the same steps manually through the user interface to see how long Revit itself requires for each step.

If there is no difference, everything is clear.

If something can be achieved faster manually, you have some optimisation work to do.

Re 2: An inefficient algorithm will probably be more or less equally inefficient in both a native .NET add-in and Dynamo.

In either case, you should benchmark your code to determine where the bottlenecks are located and what is causing them.

Here is some timer code for benchmarking:

http://thebuildingcoder.typepad.com/blog/2012/01/timer-code-for-benchmarking.html

Here are some benchmarking samples:

http://thebuildingcoder.typepad.com/blog/2010/04/collector-benchmark.html

http://thebuildingcoder.typepad.com/blog/2010/10/level-filter-benchmark.html

http://thebuildingcoder.typepad.com/blog/2010/12/more-kevin-filtering-benchmarks.html

http://thebuildingcoder.typepad.com/blog/2011/01/type-filter-benchmark-update.html

http://thebuildingcoder.typepad.com/blog/2014/04/wpf-fill-pattern-viewer-control-benchmark.html

I hope this helps.

Best regards,

Jeremy

[Anonymous]

Currently in the script Dynamo is converting Revit topography into poly-surface and we are using that poly-surface to project as a base. If we could optimize these topo surfaces it will surly become faster. Is there any way to optimise it ?

Thanks in advance.

[Revitalizer]

Hi Jeremy,

Dynamo has its own geometry engine, allowing it to perform more types of geometric operations than Revit can do.

E.g. there are more possible ways of object intersection.

As far as I can see, Dynamo can calculate geometry from input data and create/show the result in Revit as static Elements, either as ImportInstance (e.g. SAT file) or DirectShape; in this case, Revit is just the display.

But the calculation itself is being done inside Dynamo, using its own engine.

So if there is a performance issue, it may be found there, inside Dynamo.

Rudi

[jeremytammik]

Yup, sure.

Thank you.

Only Rajesh can reveal what exactly he is doing and where the bottleneck might be...

[Anonymous]

Attached is script which we are using. Dynamo is converting Revit topography to polysurface first and this topography is 650 Hectare area site with 1.00m interval contour information. If we could optimize converted to polysurface generated from contour of 1.00m interval I believe performance will get better.

[jeremytammik]

I do not know exactly what the Dynamo nodes you are using do, so I cannot say.

Yes, that does sound like a valid optimisation starting point to me, just guessing, of course.

As said, simply benchmark the steps.

Then you will know exactly what makes sense to optimise and what does not.

Cheers,

Jeremy