The “Volume” component is still the bottleneck in my definition.
I tried to use the volume of the render meshes of my Breps to speed things up, but this proved hopeless.
I wish there was a “Tolerance” input on this component that would loosen-up the absolute tolerance setting just for that operation.
No in Rhinocommon (AFAIK). But it would be good, this and joining meshes in a stable way are the major limitations to using client-facing GH definitions (such as using ShapeDiver).
Generally is faster on meshes, but depends of the mesh. Try to create a low poly mesh of your shape.
What I do often is (if possible) to compute parts and sum results together when some parts are repeated (to avoid repeat volume calculations). Also if your shape can be composed by primitive or simple shapes, you can estimate the volume calculating the volume of these simpler shapes.
Hi
You can try this code
breps = breps.Where(b => b.IsSolid).ToList();
if(breps == null || breps.Count == 0)return;
A = breps.AsParallel().AsOrdered().Select(b => b.GetVolume());
As I’m dealing with referenced geometry from block definitions, I found that this approach doesn’t work.
Well I’m already optimizing by measuring the Breps inside block definitions, instead of the geometry in all the instances…It seems tough to find “similar” or "identical shapes in my blocks.
That code is parallel.
… so is GH’s component !
I have for example changed brep to mesh and then check voume properties as @Dani_Abalde suggested. This way it is faster, but accuracy depends on mesh density.
Meshing Breps is in itself a pretty time consuming task.
That’s why I wanted to use render meshes, but sometimes it is not available, so not reliable.
You are right. I forgot to mention my tool first makes some boolean operations which are faster on mesh than on brep. In this case it may not be good solution.
Not sure what you are using the volume calculation but if it is for something that doesn’t need accuracy (comparing shapes or the like) I guess you could use a bounding box instead. I am sure you can also find an analytical volume calculation formula for those which would be an order of magnitude faster. Also you can use a parallel for or similar while doing the first.
I believe when I changed this to be parallel, I noticed that the centroid calculation was a significant portion of the solving time.
That would be a bit too coarse 
Without the centroid, it seems to go THREE times faster !
To go even further, it doable to add a “tolerance” parameter as I suggested ?
Not currently, but this is doable. There are tolerances used for computing volume, but they are not currently available in RhinoCommon. I added this to the wishlist at
https://mcneel.myjetbrains.com/youtrack/issue/RH-64317
