Performance of stack traces in errors results in high response latency (>1 second)

[ajhenry]

Great work y'all are doing here! We've run into a bit of a snag dealing with errors and stack traces.

The problem:
As bundle size increases, the duration of calculating a stack trace with source maps of an error thrown during resolver execution takes more time to compute.

We narrowed down the culprit to the following check:

graphql-js/src/error/GraphQLError.ts

Lines 144 to 158 in 9c90a23

	if (originalError?.stack != null) {
	Object.defineProperty(this, 'stack', {
	value: originalError.stack,
	writable: true,
	configurable: true,
	});
	} else if (Error.captureStackTrace != null) {
	Error.captureStackTrace(this, GraphQLError);
	} else {
	Object.defineProperty(this, 'stack', {
	value: Error().stack,
	writable: true,
	configurable: true,
	});
	}

We did a flame graph for an error thrown and this resulted in the following:

It takes this amount of time regardless of which resolver throws an error.

We currently bundle our server (along with tree-shaken dependencies) in a single file so we can upload it to a lambda. We are at around 76MB for our total bundled file which is not great (😟) but still very usable for us in production.

Our workaround right now is to explicitly set captureStackTrace and bypass having to perform this calculation. This decreases the execution time from 1154ms to 20ms. However, we are left with no stack traces.

Any suggestions or help would be greatly appreciated, thanks!

[yaacovCR]

Duplicate of #2800 ?
That issue suggests disabling source maps?