maybeDeepFreeze takes ~200ms on big arrays

[Banou26]

Intended outcome:
Apollo not taking ~200ms deepFreezing big arrays when I'm updating a reactive variable.
Or maybe make an option for us to disable deepFreeze in development as it'd also fix #6813.

Actual outcome:
Apollo deepFreeze the array everytime i make a change to the reactive variable and it takes around 200ms.

How to reproduce the issue:
Set a big array (more than 1k items) of objects in a reactive array & make a query that fetches it.

Versions
"@apollo/client": "^3.2.9"

[benjamn]

@Banou26 Very much appreciate your performance stress-testing!

I'm cautiously optimistic that this PR could have a big impact on the amount of freezing that happens in development. Specifically, since result objects are canonicalized before they're frozen in the new system, they won't be re-frozen if the canonical object ends up having the same structure as it had before (even though it might not be === to the previous object, prior to canonicalization). I'm guessing that most of your array elements are unchanged in structure, so they wouldn't need to be repeatedly re-frozen. Also, maybeDeepFreeze will no longer be used for freezing result objects, since we can incrementally freeze new objects using a shallow Object.freeze call. Finally, in this system, only [object Array] and [object Object] objects get frozen, which should finally fix #6813, since byte arrays have Object.prototype.toString.call(array) === "[object Uint8Array]".

[jimrandomh]

Also note: if you aren't using a bundler that replaces process.env.NODE_ENV at compile time (eg if you're using Meteor, or if you're not doing bundling of server code at all), you'll get bad performance, and maybeDeepFreeze is one of the places that's heavily impacted. See this PR.

[hwillson]

It doesn't sound like there is an outstanding issue here, so closing. Thanks!