Sometimes, the profiler seems to pick a random component to account for the missing execution time of the definition.
Except this time, my component has an alibi : it couldn’t run because the trigger was always “false”.
This trigger is activated through Human UI, and I know I didn’t press that button.
So it seems to take the total effective execution time, substract to that the sum of all the execution times of the components and pick a scapegoat to be responsible for the difference.
You are assuming your C# component is correctly handling the OK input and correctly implemented.
Without seeing the code we can only guess.
In that case your OK is most likely set to true after all. At least I was not able to reproduce:
Both C# script components have the same code.
Where is the performance analyzer from?
It’s from the Pancake plugin. It’s awesome.
I’ll live without it for now.
Anyway, as far as I can tell the built-in profiler widget gives correct values. I would check and double-check the OK input is really set to false.
OK. I can’t repeat the problem now.
It has happened several times to me in the past : some random component supposedly taking ages to process.
I think it’s an artefact of some kind…
Well some kind of “Official” performance analyser would be welcome anyway.
I mentioned:
By default, Pancake’s perf analyzer just displays timings from GH’s profiler, similar to MetaHopper’s Bottleneck Navigator. So theoretically in this case it won’t interfere with GH’s execution pipeline.
As for your issue, Grasshopper’s C# component needs to call the old CodeDom compiler, which can be slow under certain circumstances, e.g. when the host NGEN is busy.
