>
> interface LazyPerformanceEntryList {
> bool HasEntryType(string);
> PerformanceEntryList getEntries();
> PerformanceEntryList getEntriesByType(DOMString entryType);
> }
>
This sounds awesome. I updated the doc with this text.
To the earlier point about New-ing each PerformanceEntry as the call is
made, I think our current implementation is similar to Gecko, though I
think for resource timing we can inplace-new the entries: we know operator
new to be a major bottleneck for performance timing.
The nice thing about the existing perf timeline spec is that there is room
for optimization on this front down the road --- at least in most place.
I'll be the first to admit that user timing is defined a bit adversarially
for efficient implementation. Though the user timing v1 ship has sailed, my
hope is we can at least have the observer layer be friendly to future apis
defined with zero-allocation-at-calltime overhead in mind.
Fun fact: Things like WebTracingFramework actually keep all their "user
timing" calls js-side such that you're actually pushing the
mark/mark/measure items plus a timestamp into a typed array. The only
js<->native bridging is to get the timestamp. Its pretty neat. :)
