Making a component “Task Capable” When a component implements the IGH_TaskCapableComponent interface, GH will notice and potentially call a full enumeration of SolveInstance for the component twice. The first pass is for collecting data and starting...

The latest WIP includes a new behavior in Grasshopper that we are experimenting with to improve performance; multithreaded component solving.
The following four components have been modified to perform calculations using multiple threads.
Contour
Dash Pattern
Divide Curve
Boundary Surface
We are decorating these components with small dots in the upper left corner to help you understand the component’s capabilities and current ‘mode’ of operation.
No dots : the component does not currently s…

Thanks, Steve.
I already knew about the multi-threaded components, but the TaskCapableComponent is news to me, I’ll definitely take a serious look into it to understand if it handles the SetData bottleneck efficiently.

Hi @aristocompasso,
If outputting is taking a long time, I’m assuming that you’re outputting a large number of objects (thousands of points, etc).

You’ll likely get much better performance by directly setting the Grasshopper type instead of outputting the Rhino type. For example, instead of DA.SetData(0, MyPoint3dList); you could use DA.SetData(0, MyPoint3dList.Select(x => new GH_Point(x));

This avoids the Cast functions, which are very expensive when called that many times.

As an example, generating and outputting 100,000 random points takes 565ms using Point3d, or 19ms when using the Linq conversion to GH_Point. Discussion here.

Hi Cameron, thanks for your input.
I was already aware that the Grasshopper.Kernel types have better performance than the Rhino.Geometry types.

camnewnham:

From memory this applies to compiled components in just the same way as it does to Script_Instance, but please correct me if I’m wrong.

It does apply, but I’m not sure that the difference is as noticeable because the compile components already offer better performance than the script components. To give you an idea on this specific component I tested the second case on your screenshot.

Rhino.Geometry

Grasshopper.Kernel.Types

SetRgVector3d() completed 1915201 in 903ms

SetGhVector() completed 1915201 in 356ms

39,4%

of Rhino.Geometry

SetRgPoint3d() completed 1915201 in 942ms

SetGhPoint() completed 1915201 in 401ms

42,5%

of Rhino.Geometry

So, an improvement, but nowhere near the 28.5x magnitude. The good news is that the compiled component sets +/- 10x more points than the script component in the same amount of time.
I’m wondering, though, if using the Grasshopper.Kernel.Types throughout the component (calculation stages) has advantages over using the Rhino.Geometry types in terms of the overall performance of the component… I have to check it out.

Another thing that I’ve found is that sometimes the perceived performance of components is not related to the IO directly, but rather in adding to the display pipeline (regardless of whether the component is hidden/visible).

One thing that might be worth trying (for testing only, to isolate issues) would be Rhino.RhinoDoc.ActiveDoc.Views.RedrawEnabled = false. Presumably this wouldn’t have any effect on numeric outputs, but on GeometryBase types I get a pretty major ‘performance’ increase.