How to make my GH deffinitions lighter


(Gabriel Ganzarolli) #1

I need to make this model lighter and faster.
How can i do it?

sandman - (54.9 KB)


Most of the time is spend in the Area component.

// Rolf

(Gabriel Ganzarolli) #3

hmmmm, right, can u tell me how to solve?


I could give it a try (but not now), and only if you type “you” instead of “u”. :wink:

I find that GetArea is a function available in RhinoCommon, which means that it is possible to script this. And when scripting one can take the incoming list of Breps and run the calculation in parallel. Sometimes soing so does the job very much faster

Have you tried scripting?

// Rolf

(Gabriel Ganzarolli) #5

hahahaha, right, could you?

i never tried scripting, but i can learn how.

thanks a lot :slight_smile:


Rhino6 runs the Area component in parallel, so R6 makes a significant difference.

Remains SDiff and SInt which doesn’t support parallel (not yet)

Edit: RhinoCommon methods that can be used if scripting and run in parallel:

Profiling results in Rhino6

// Rolf

(Gabriel Ganzarolli) #7

hmmm, unfortunaly i dont have the v6 yet :frowning:

Is there an other way to find de center of a geometry for a lower cost thsn the Area component?

(Michael Pryor) #8

I find that GetArea is a function available in RhinoCommon

noticed that also new in R6 rhinocommon. Is it just a faster area calc than area mass properties? Have not tried it yet.


I have not either. And time is 4:00 in the morning here in Sweden so I guess I won’t try it exactly right now… :slight_smile:

Good night!

// Rolf

(Gabriel Ganzarolli) #10

hahahaha, okay.

Good night from Brazil. :wink:

(qythium) #11

Without getting into parallel computation yet, one thing I noticed is that your initial surface has a very high point count (76 x 24), probably you got it from interpolating points. This makes components like Area very slow due to all the NURBS calculations.

Using the _Rebuild command to reduce it to U=10, V=4 points, the area components run about 15x faster

(Gabriel Ganzarolli) #12

WOW, niceeee.
ill try it.
Thanks a lot!!! :slight_smile:

(qythium) #13

Another comment - you can use the Bounding Box to get a much quicker estimate for the center of your geometry, rather than Area or Volume calculation, which are accurate but slow.

(Gabriel Ganzarolli) #14

Yes, it defnly got quicker, thank you a lot! :smile:


OK, good morning. Here’s a version with all the optimizations suggested by @qythium PLUS two new script components called SDiff_Parallel and SInt_Parallel (C# scripts). The results are from Rhino6. Difference in speed:

Edit: Ops, forgot to internalize the simplified mesh. Fixed:
sandman - Copia - (30.8 KB)

SDiff = From 7.6 to 1.5 sec (1.0s for R5, see far below):

SInt = From 4.9 sec to 1.2

And runtimes for all components (R6) look like this:

Runtimes for Rhino 5 with the same Gh definition:

@DavidRutten: For some reason the RhinoCommon SInt script call doesn’t give the same result as the GH SInt component (There’s one or two missing plates when using my SInt component)

Summary: Rhino 5 seems to be significantly faster, except for the Voronoi component.

Have a good one.

// Rolf

(qythium) #16

It might be an off-by-one error somewhere in your code - I didn’t try looking at it too closely but here’s a quick one-liner using PLINQ that does essentially the same thing, a little faster :grimacing::

G = B.AsParallel().SelectMany(b => Brep.CreateBooleanIntersection(b, B2, 0.0001) ?? new Brep[0]);

sandman - Copia - (28.3 KB)

Running on Mac Rhino 5, but also getting different results with the native SInt component.

I also tried setting the tolerance to RhinoDoc.ActiveDoc.ModelAbsoluteTolerance but that didn’t affect the result counts.


Yes, removing “- 1” gives 262 :

sandman - Copia - (28.5 KB)

Still one missing up to 263 though…

// Rolf



I don’t have these plugins so can’t see all of your code. From what I can see though, Area is being used more often than necessary. These four are redundant - the Scale components they feed could all use the first Area component below the Geo param:

I’m guessing that the Area components after SDiff (which makes no sense, by the way - area of a solid?) could be using the PopGeo points instead of Area centroids?


The last file (sandman - Copia - should contain only std components (I also didn’t have any of the extras).

Edit: The area components doesn’t add much to the execution time though:

// Rolf

(Michael Pryor) #20

area of a solid

You can get total surface area that way. But in this case it doesn’t make sense for centroids.