I try to leave my GH components as basic as possible to maximise what my guys can do after the initial C# runs.
BUT
I feel like their is a perfomance impact by using additional GH components to do the legwork after that code, I have no way to measure this other than a “feeling” that it runs more sluggishly as per below than if i finish the pipes etc all in C# component, and faster again by jsut writing the whole thing as RC C# plugin running directly in rhino.
Any basis to this? is their a way to boost GH perfomance? (in this example its not a major issue, but in other larger constucts its plaguing me.
It is quite dependent on the use case, but in general:
If you implement a RhinoCommon class/method in a C# scripting component in a one-to-one manner, the equivalent standard GH component will likely be faster, since it is compiled (edit: this reason is incorrect). That said, more complex definitions (with many RhinoCommon calls) could be faster if implemented in a scripting component (or a proper compiled plugin), since you can optimise the algorithm/implementation, there is no costly input/output/casting of data, you can multi-thread the code (again depending on the case) etc.
Also, I would recommend profiling your definition/code to get explicit performance data. For GH definitions turn on the profiler widget (Display -> Canvas Widgets -> Profiler), for C# scripting you can use the Stopwatch class.
Also II: Piping is an inherently costly method. Unless you actually need to render the high-quality NURBS representation, you could use another method (mesh piping comes to mind, think there’s a plugin for this as I recall).
The C# component is also compiled and will run exactly as fast. The overhead with script components vs. plug-in components is that the data that goes into script components is duplicated for each call, to prevent changes made to that data inside the script for percolating to the same data being held elsewhere. This precaution is not made for plug-ins because I assumed that people using Visual Studio could be trusted somewhat more to write safe code.
You are correct in general that the script components will be somewhat slower than native ones, but the difference is not due to being compiled or not. Expressions however are way slower than either because they really are interpreted at runtime.
Thank you all for the feedback. The difference for me in coding between the two options is the extra mileage in having to setup a snapin panel and all the dynamicdraw overhead when using a straight c# plugin. I guess I will pick my battles moving forward and write the less taxing units as GH components and the more cpu intensive ones as plugins. My guys love being able to pull curves from one gh component directly into another though… decision will have to flexible I guess…