Do you have a use case where you want to create 5000 errors and you have noticed an actual slow down because of the O(n) error lookup

These types of micro benchmarks have a history of not paying off in practice.

The amount of throuput we do, we've run into this issue numerous times, and it effects us hitting our SLA. So yes, this has had a significant impact on performance. In an ideal world, there wouldn't be so many errors, but they are out of our control.

Hi @bbakerman, thanks for looking at this. I was working with @wasche on this and at the time I had hooked up VisualVM to get some CPU profiles. The way I ran this test was to throw a bunch of queries at our GraphQL service. Each query fetched a few hundred items from one service, and then went to a few supplementary services to fill in the fields for those items. I took one of those supplementary services offline to see how the system responded. The issue we were seeing is that if one of those services went down, GraphQL's CPU usage would spike and the service would be severely degraded.

Sadly I don't have the full results anymore but I do have this screenshot (below) showing that within my test, of all the time used by ExecutionStrategy.completeField, 93% of it was spent in ExecutionContext.addError. I believe I ran the test for only a minute or two, so the 25 seconds in the screenshot represents a large amount of work.

I had added a workaround in our service when we were running 9.2, but now that we're upgrading to 12.0, our workaround no longer works (we were relying on the public constructor of ExecutionContext to subclass it and override the addError behavior).