Re: [PerformanceTimeline] API/WebIDL related feedback

One of the original reasons for only exposing the .getEntries() family 
of functions (which return copies of the array) vs. a 
performance.entries array that the user can directly access, is that the 
PerformanceTimeline array may be changing at any point in time. Entries 
can be added to the end or middle of the array, or removed entirely both 
by async browser events (eg. new ResourceTimings complete) or by 
userland (eg UserTiming's clearMarks() is called).

What we wanted to avoid was making it easy for developers to mistakenly 
blindly iterate over an array that could be modified underneath them.  
Having new entries added to the end of the array probably won't cause 
problems with most for loops, but PerformanceTimeline-participating 
events could either remove entries from the array or even add 
PerformanceEntrys in the middle of the array.  For example, 
ResourceTimings don't get added to the array until they complete, but 
since the PerformanceTimeline array is sorted by startTime, new entries 
could suddenly appear in the "middle" of the array before current the 
last event.  This could lead to all sorts of problems if someone is just 
blindly iterating over the array with a for (...) loop.

For these reasons, we chose to simplify things and only expose the 
.getEntries() family, which return static copies of the 
PerformanceTimeline at-that-point-in-time that will never change.

- Nic
http://nicj.net/
@NicJ

On 8/23/2013 3:43 AM, David Bruant wrote:
> 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
>