Profiler accuses innocent

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.

I’m no C# expert, but the code says “If OK” :

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:

Yeah, well find the components that have long execution times in there :

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.