RE: Resource timing buffer

If no vendor implemented that, I would suggest not keeping that statement. Developers may be given a lot of uncertain imagination if we keep it there. For example:

1)      Consider the case the onresourcetimingbufferfull triggered but the clear method is never invoked, shall we keep the incoming entries during callback, and drop entries after callback? it is weird and developer won't get a stable result. Keep all the entries as we regard they interested in every entry? then why we keep   "setResourceTimingBufferSize" method, the "N" become a read control rather than a buffer control.

2)      Even clear method is invoked during callback, what if the temporary buffer is beyond the buffer size at the meantime? (Processing model 3.20.4 said copy all the temporary when clear), will 2nd "onresourcetimingbufferfull" event be fired and lead to nested callback?

3)      Consider my call back looks like {step A..; step B:getEntriesByType(); step C...}, if a new entry comes during step A, will the getEntriesByType() return "N+1" entries.


To simplify the spec and regard Nic's concern, I suggest a replacement like: PerformanceResourceTiming<http://www.w3.org/TR/resource-timing/#performanceresourcetiming> of the resource that fetched during the callback will be held and a storing trial to PerformanceEntryList<http://www.w3.org/TR/performance-timeline/#performanceentrylist> after the callback.
And the processing model can be changed like:
3.20: if the primary buffer is full, drop PerformanceResourceTiming<http://www.w3.org/TR/resource-timing/#performanceresourcetiming> object and terminate. Otherwise, store the PerformanceResourceTiming<http://www.w3.org/TR/resource-timing/#performanceresourcetiming> object.
3.21: check if the primary buffer is full or not, if full, onresourcetimingbufferfull<http://www.w3.org/TR/resource-timing/#dom-performance-onresourcetimingbufferfull> must be trigged.

In this case, developers do have chance to clear buffer in suggested 3.21(once buffer achieves N, not N+1), then drop of next entry(in suggested 3.20) can be avoid. :)

Thanks
Pan

From: Nic Jansma [mailto:nic@nicj.net]
Sent: Tuesday, April 30, 2013 9:38 AM
To: James Simonsen
Cc: Arvind Jain; public-web-perf
Subject: Re: Resource timing buffer

While in onresourcetimingbufferfull, getEntries() was intended to be "stable", i.e. it should have "buffer size" (N) number of entries.  New RT entries occuring during the callback would go into a queue.  Then, per option #1 in onresourcetimingbufferfull, if clearResourceTimings() is called, the first N entries are removed and N+1 queued entries onward take their place.

Without the onresourcetimingbufferfull text, I'd be worried that the developer could lose RT events.  If they're interested enough to listen to onresourcetimingbufferfull, they probably want every single RT event, and the only way to work around the possibility of lost events during the callback is to just set a huge buffer instead and call it a day.

But it does complicate things and the description is kind of hard to follow.  I can't think of any other web APIs that require this level of buffer management to follow the lead from?


- Nic

http://nicj.net/

@nicj
On 4/29/2013 9:18 PM, James Simonsen wrote:
That implies that the buffer can change while the onresourcetimingbufferfull callback is running. Is that expected? That'd mean it's not safe to clearResourceTimings() after getEntries(), because a new entry may have appeared in the meantime.

In Blink, this would only be possible if a synchronous request took place during the callback. I don't think that's something we should go out of our way to support.

James

On Mon, Apr 29, 2013 at 6:10 PM, Nic Jansma <nic@nicj.net<mailto:nic@nicj.net>> wrote:
I believe the idea was to give the developer the opportunity to smartly manager their RT buffer instead of just setting it at 10,000 (and consume resources) so they didn't have to worry about it.

For example, a developer could leave the default 150 buffer size and:
1) Listen to onresourcetimingbufferfull
2) When onresourcetimingbufferfull is triggered:
2a) getEntriesByType(...) and analyze/process/submit/store these 100 resources if they wanted
2b) clearResourceTimings()
3) In the meantime, the browser has been caching any new entries and takes the action defined in onresourcetimingbufferfull (http://www.w3.org/TR/resource-timing/#dom-performance-onresourcetimingbufferfull) after the callback has completed.
4) The developer can now analyze any new events that came in during step #2 or wait for the next onresourcetimingbufferfull

Otherwise, if any new RT events come in after #1, and the browser stops recording them, the developer has no way of knowing they occurred and cannot retrieve them.


- Nic

http://nicj.net/

@nicj
On 4/29/2013 7:32 PM, Arvind Jain wrote:
http://www.w3c-test.org/webperf/specs/ResourceTiming/

Re. this comment:
onresourcetimingbufferfull attribute
....While executing the onresourcetimingbufferfull callback, PerformanceResourceTiming will continue to be collected beyond the maximum limit of the resources allowed....
I tried to look up why we added it and couldn't find anything. Currently this logic is not implemented by IE and Chrome.

Should we remove this? i.e. once the limit is reached, don't store new resource timing objects irrespective of whether you are executing this callback or not.

Arvind