W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2013

Re: Resource timing buffer

From: James Simonsen <simonjam@google.com>
Date: Tue, 30 Apr 2013 10:21:36 -0700
Message-ID: <CAPVJQi=aZ3LiHqF6MNviQxj9jUwQHHJk6Cmme0G4D1bF+AiLuA@mail.gmail.com>
To: Nic Jansma <nic@nicj.net>
Cc: Arvind Jain <arvind@google.com>, public-web-perf <public-web-perf@w3.org>
I wonder if we have to say this at all. The web is single threaded. I
believe most of the specs assume that. It's up to the browsers to maintain
that illusion and this could just be part of it.


On Mon, Apr 29, 2013 at 6:38 PM, Nic Jansma <nic@nicj.net> wrote:

>  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?
> - Nichttp://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> 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.
>> - Nichttp://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
Received on Tuesday, 30 April 2013 17:22:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:35 UTC