C# component speed

Replies to This Discussion

Permalink Reply by Anders Holden Deleuran on November 9, 2017 at 8:44am

The only way to objectively test performance is through profiling, in C# you might use the Stopwatch class for this (edit: I recall David having written about this subject, hopefully he'll chime in here). Out of practical development concerns, one might suggest avoiding referencing the Grasshopper SDK as much as possible. That is, for instance using native .NET and RhinoCommon types/data structures as much as possible, and only wrapping these in GH types when necessary (Kangaroo2 follows this principle to a large extent for example). That said, I wouldn't expect there to be much cost involved in using a lot of GH types in the core code.

Permalink Reply by Shimpei Kojima on November 10, 2017 at 5:36pm

Dear Anders,

Thank you for replying me.

As you said, maybe I should use native .NET and RhinoCommon....

Can you tell me where "Kangaroo2 follows this principle to a large extent for example" is said ?

Best,

Shimpei

Permalink Reply by Anders Holden Deleuran on November 11, 2017 at 3:42am

For instance, have a look at how Dan has written the Kangaroo2 goals: they for the most part only implement .NET (i.e. using System.Foo) and the RhinoCommon geometry (i.e. using Rhino.Geometry) namespaces. Using standard C# to structure the PPos, Move, and Weighting arrays, and not getting the Grasshopper namespace involved at all here. The Kangaroo2 solver does though, since it does things that depend on it (updating the component over time, structuring goal data output into DataTrees etc.).

Permalink Reply by David Rutten on November 12, 2017 at 10:42am

Yeah Anders is right. Step 1 is always profiling. There's no point optimizing code until you know where the bottlenecks are. The Stopwatch class in System.Diagnostics is the best way to measure elapsed time, do not rely on DateTime.Now or DateTime.UtcNow, they have low accuracy.

Referencing assemblies shouldn't matter for performance. Choosing the right collection types can make a huge difference. Array vs. List vs. Stack vs. Dictionary vs. SortedList vs. HashSet vs. DataTree, .... you need to understand what operations you need most often and then decide which collection is best for you.

The C# component is standard .NET, however all code is compiled using DEBUG mode. This helps with finding problems, but sometimes you will get much better performance when you build RELEASE mode (especially with lots of Array interactions or GetPixel/SetPixel stuff).

But, start by profiling your code.

Permalink Reply by Shimpei Kojima on November 15, 2017 at 11:42am

now I started to modify code using stopwatch class.

Thank you for letting me know stopwatch class.

Permalink Reply by Petras Vestartas on November 9, 2017 at 8:58am

Normally you have one .dll / Visual Studio project with core functionality and component should work only as interface for calling functions. It is also easier to track what you did some time ago.

But in general if you are not outputting 10 of thousands elements from one component like with Kanaroo2 Goals , then it is your solution and solver which should be optimized. Multi-threading is additional option, but you have to know how to do it correctly.

Permalink Reply by Shimpei Kojima on November 10, 2017 at 5:40pm

Dear Petras,

Thank you for replying me.

In the future, I will analysis large scale building (many elements included, maybe over thousands)

I think I have to learn Multi-threading but it looks very diffcult and I worry about it will work in GH C#....

Permalink Reply by peter fotiadis on November 9, 2017 at 10:52am

Impossible to suggest (or "suggest") anything  without some piece of "representative" code. Have in mind as well that Rhino is a surface modeler meaning that pretty much any "solid" related Method is considerably slower than "some equivalent" in solid modeling aps.

But other than that you can entirely skip DataTrees with a variety of ways especially if you have plans to write some code that is as GH neutral as possible (that way you restrict changes by focusing to RhinoCommon classes - in order, for example, to port your code to other holistic parametric AEC platforms like AECOSim + Generative Components + structural verticals [my case] and/or MCAD apps etc etc etc)

Permalink Reply by Shimpei Kojima on November 10, 2017 at 5:50pm

Dear peter,

Thank you for replying me.

I didn't know It depends on that what Rhino focused on...

 I want to make component like 'Karamba' but I'm not sure when it will be done...

Permalink Reply by peter fotiadis on November 11, 2017 at 12:11am

Well ... I would suggest to post a portion (some Methods, that is) of your code (VS "many" elements) and we'll exploit ways to skip DataTrees (if "portability" is a goal) or // ways to do it.

Keep in mind that there's no magic red button that if pressed delivers wrap speed - // without some/proper scheduling is kinda a man without a Ducati.

On the other hand ... in real-life ... there's verticals already working fine within a given established AEC platform (Rhino/GH are NOT the things to use). Me? I'm working with Bentley Systems stuff (AECOSim + Generative Components + you name it).

There''s a clear and present danger to reinvent the wheel here.