- From: David Bruant <bruant.d@gmail.com>
- Date: Fri, 23 Aug 2013 09:43:34 +0200
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: James Simonsen <simonjam@google.com>, public-web-perf <public-web-perf@w3.org>
Le 23/08/2013 04:09, Boris Zbarsky a écrit : > On 8/22/13 4:30 PM, David Bruant wrote: >> Maybe it should just be .entries, then (instead of .getEntries() )? > > As the spec is written right now getEntries() returns a new JS Array > object containing entries That's the part that I missed. > the discussion was about whether the items in the array are also new > objects or just references to existing objects. > > In your proposed setup, what would .entries return? I guess always the same array. > If an Array object, what happens when you try to push() or pop()? If it's the same array, it works as expected. It opens the possibility that people mess up with it, yes :-) But it's not the DOM tree or anything really crucially important. It's perf measurements. If people want to shoot themselves in the foot, I'm not too worries of the consequences of this one. > Does performance.entries == performance.entries test true? That wouldn't shock me. Performance nerds will notice that creating a new 10000 entry array each time getEntries is called requires a new allocation, makes 10000 new edges for the GC Mark-and-Sweep to traverse. One of these performance issues that are hard to even notice and harder to diagnose. If the array remains the same, GGC will put it in old generations and visit it very rarely (as it does with the internal representation of the data anyway, I imagine). David
Received on Friday, 23 August 2013 07:44:03 UTC