algorithmic modeling for Rhino
Hello everyone,
Now, I'm scripting Structural Analysis Component in GH by C#.
It goes well in small model(beam and column x 8) but in large model (beam and column x100) it takes a long time to solve.
I knew I shoud improve my code to avoid multiple loop(such as 'for loop')
but I don't know I should avoid GH Class (such as DataTree Class)
Is there anyone to know how GH Class delay solution time?
Best,
Shimpei
Tags:
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.
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
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.).
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.
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.
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#....
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)
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...
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.
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson.
Powered by