Performance Issues because of AbortSignal (Execution Cancellation Plugin)

[pozylon]

This line here likely makes yoga 10x slower because it almost spends all of it's time adding event listeners when an AbortSignal is provided through the execution context. I just wanted to share my finding here and I'm currently looking for a solution and I don't have an idea yet how to fix that...

https://github.com/ardatan/graphql-tools/blob/5ecdb9dc6f119189892aeb9f284a1fae306b7ff9/packages/executor/src/execution/promiseForObject.ts#L18

Maybe it's some kind of regression because of this commit here: https://github.com/ardatan/graphql-tools/commit/020b9e47b51f9847bf915d ?

[pozylon]

Of course i'm doing some artifical request here but still the effect is dramatic the more objects there are in the response:

Response time of that API Request above with useExecutionCancellation(): ~4000ms Response time of that same API Request without useExecutionCancellation(): ~900ms

[ardatan]

Could you test with the following alpha? @graphql-tools/executor | 1.3.10-alpha-20241224080220-7cec9a36c8869567ca685def6970f80d29f8b7f5

[pozylon]

much better !!

[pozylon]

This shaves off another few milliseconds btw:

 //const promises = Promise.all(Object.entries(object).map(async ([key, value]) => {
  //    resolvedObject[key] = await value;
  //}));
  const promises = Promise.all(Object.keys(object).map(async (key) => {
      resolvedObject[key] = await object[key];
  }))

[ardatan]

We did a refactor there recently. Could you try it again and let us know if the performance issue persists. Also cc @enisdenjo

[ardatan]

Closing due to the inactivity. If the issue persisted, we can always re-open the issue! Thanks for the collaboration.