Improve performance of walk utility

[AbhiPrasad]

We have a walk util which we use to walk objects to normalize them.

sentry-javascript/packages/utils/src/object.ts

Line 312 in 0a6e535

export function walk(key: string, value: any, depth: number = +Infinity, memo: MemoFunc = memoBuilder()): any {

This is used extensively throughout the SDK, primarily through

sentry-javascript/packages/utils/src/object.ts

Lines 373 to 379 in 0a6e535

	export function normalize(input: any, depth?: number): any {
	try {
	return JSON.parse(JSON.stringify(input, (key: string, value: any) => walk(key, value, depth)));
	} catch (_oO) {
	return '**non-serializable**';
	}
	}

@timfish and some others have reported OOM errors on coming from the walk function - which shows that it is not always super safe to use. We've also seen issues like #4470.

We should try to do a couple things here:

1. Profile normalize and walk, see where the bottlenecks are in various scenarios. It's used in electron and react native also, so it'll be interesting to see the effects on that platform.
2. Experiment with adding a limit to the number of leaves, not just limiting serialization depth
3. Explore going beyond using a JSON.Stringify replacer to more a more rigorous object traversal to try to improve efficiency.

We can test potential performance improvements with https://github.com/getsentry/sentry-sdk-benchmark/

In a slightly related note, we also use JSON.stringify a lot throughout the codebase, and it's not always clear when to use walk to normalize. We should make the usage consistent, perhaps by extracting into distinct helpers based on the use case. This also means we could have "more expensive" and "less expensive" normalization functions - perhaps that will just alleviate the issue we have here.

[timfish]

For ref. here is the open Electron issue:
getsentry/sentry-electron#263

I managed to reproduce this once before by inadvertently console logging a huge object which referenced a DOM element. This went through JSON.stringify + walk and caused OOM very quickly even with the walk depth limited to 50.

I've also seen Webpack HMR trigger the bug occasionally with whatever it does on update.

I suspect it is not enough to only limit the depth we serialise since that can still result in huge objects. We should probably be attempting to limit the number of "leaves" too.

[AbhiPrasad]

Here's a related Vue issue: #2957

[productdevbook]

vue 3 some problem.

[AleshaOleg]

Is it still relevant? I can take a look into it, but the walk function isn't there already, so I need some updates on what should be done here