Well you sent me down quite a rabbit hole, but yes I was able to confirm what you said -- that actually constructing the no-proto objects was not the main cause of the bottleneck.
What *was* a problem was that I was using a WeakMap to cache the is-deep-immutable property, and what I learned after I did my investigation is that it was the sheer number of objects tracked in that one weakmap (millions or more) was the source of almost all the slowdown, which the large chunks of unresponsiveness being caused by the rebuilding of the hash table. I couldn't see this at all until I changed perf tools. I had been using browser devtools to profile and debug node code, but running the problematic code *natively* in the browser magically causes the "line by line accumulated perf cost" gutter show up so that you can see *where* in a particular function the majority of its costs are incurred. This turned out to be tremendously important because when the expensive call is into a native function like WeakSet.add, the native function will never show up in the flamegraph. I think that's kind of a shame, really, because the absence of that information just makes it look like the parent function containing that call is bizarrely expensive for no reason at all, at least until you get the line-by-line shades-of-yellow view that shows you what's *really* going on On Mon, Apr 20, 2026 at 3:34 AM Ben Noordhuis <[email protected]> wrote: > On Sun, Apr 19, 2026 at 6:09 PM Conrad Buck <[email protected]> wrote: > > > > Greetings from TC39-land! I'm currently working on a proposal for > immutable data structures, and there's a puzzle I'm trying to solve that I > was hoping someone with knowledge of engine internals might be able to help > me out with. In the spirit of the car talk puzzler, here we go: > > > > I'm hoping to be able to use deeply-frozen no-proto objects and arrays > as the language basis for records. The advantage here is that there is no > risk of prototype pollution, which is appropriate for a data-only structure > such a struct/record is. > > > > While I find it extremely promising that the language already contains > these objects and has well-defined semantics for them, the trouble I have > is that I can't figure out how to construct them in a reasonable amount of > time. > > > > The naive way is like this: `Object.setPrototypeOf([], null)` and it's > very, very slow. > > > > Is there any faster way to create these objects? I was hoping that > `structuredClone` might let me make one the slow way and make more the fast > way, but no it copies a no-proto array into an array-proto array. > > > > `new Array({ __proto__: null })` was another idea I had, but proved > similarly fruitless as it sets up the array prototype. > > > > If there was a workaround -- a reasonably performant way to get > instances -- a Records feature could be introduced to the language with a > performant polyfill, making them usable right away. If not, records would > be more like a hard-breaking change. I'd really like to understand which > situation we're in! > > > > All the best, > > Conrad > > Object.setPrototypeOf(arr,null) or arr.__proto__=null is about as fast > as it gets. > > I don't know about "very, very slow" - I get 5 million ops/sec on my > crappy 11 years old laptop. Seems plenty fast? > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to a topic in the > Google Groups "v8-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/v8-dev/GRYbPP8WA_Y/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/v8-dev/CAHQurc954UZoDasL6pPz_574rk_hphBBQj34K8yagH7RNMzpQA%40mail.gmail.com > . > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAJG1B%2BYu0D1UBsL9KFMQf2pZjvh0U8JA8gGPbxUAKyKMx4xuRA%40mail.gmail.com.
