This thread is incredible hard to follow due to incredible bad naming. I know it’s already solved. (Having an issue because of mixing local and class global variables (=fields)).
But it took me 10 minutes to even figure out what you are actually trying to do (better).
There are naming conventions for a very good reason! But even with violating them, at least proper naming of members is helpful. Humans are not robots, so unless we obfuscate on purpose, it is terrible practice to name variables “B” or “bb” or “a, b, c, d” and functions after “DoSomething”, “evaluate”. And even if there is this 1% rare case where this would make sense, then please put a comment somewhere explaining in 3 sentences what this is all about. You can find so many bugs just by figuring out a logical error by reading a proper sentence. Without having readable code, it makes no sense to optimize for performance, especially if you violate ‘Single-Responsiblity’ all over the place.
You’re right, I renamed it (although a noob like me would have probably typed what I initially named it as)
The original post had nothing to do with code optimization, but simply where variables had to be declared in grasshopper 's c# component. Although I totally agree I should have added a note on the OP to explain what the code was doing.
The second question (I didn’t know would spark much interest) was simply about python vs c# vs native c# speeds. So no one asked for optimization…
Naming wasn’t really relevant, and since I made this as part of an answer for another forum post, I didn’t spend much time in the code, but explained outside of it. Especially because the script was part of a much bigger definition. The naming convention I used mainly came from the default variable names Grasshopper gives us when we instantiate a c# component
For the “DoSomething”, it’s a wink to Peter’s code but once again, not relevant for this topic IMO.
Don’t worry, I was just meant this in a more general way, not addressing you here.
The reason why performance is not comparable from Iron(!)Python - and C# script component is manifold. This example shows again that it’s important to measure the right thing! If you use the same algorithm, encapsulate it in one function, measuring only that one function (more than once, SRP), the performance would be quite similar. This is because it likely creates the same IL code.
What you actually measure with the GH Profiler is more than this, and of course as already mentioned, the difference is for the most part up to the ‘Input’ and ‘Output’ of the data and on-the-fly compiling. There are tricks to bypass this in a C# script component. E.g. you can feed in as one object, casting it to the right collection. This prevents that the data is actually copied (for safety and mapping reasons).