Re: Notification for new navigation timing entries

Hopefully we copy microtasks spec for the model of when the event fires.

But also, thought: Why are we passing in the events into the callback?
Can't the caller just do getEntries? Remember if we do that we've actually
got to construct the newly added events in a separate array from the global
buffer. This could make efficiently implementing the getEntries hard: in
chrome, we hold off creating the JS bound objects for an entry until you
call getEntries, which lets us *buffer up* the performance events at high
speed. Thats important for making this api be performance-safe.

Broadly, I think we should opt for the primitives here... the event saying
it was added. If you want to then get the entries, use getEntries. or
getEntriesOfType.

Also, how does this behave when the buffer is full? The buffer sizes seem
to be specifed per event type, which would imply that the event added is
called per event type? If one buffer is full and another isn't what
happens? Should this event be per event type?

I don't know the right solution but I smell some architectural fragility
here. We need to remember this is a performance api... at every step of the
way, it should be lean and mean. :)

On Wed, Oct 22, 2014 at 4:01 PM, Ilya Grigorik <igrigorik@google.com> wrote:

>
> On Wed, Oct 22, 2014 at 3:28 PM, Nat Duca <nduca@google.com> wrote:
>
>> Forgive me for replying late in this thread but this direction is very
>> concerning for non-navigation uses of the timeline. Things like putting
>> frames in the timeline, for instance. We're loookign at huge numbers of
>> these callbacks, proportional to how much we want to put in the timeline.
>> This then means that putting things into the timeline is performance
>> disturbing!
>>
>> Please, please please, consider the mutation observers model where a
>> single event is fired on the microtask unwind.
>>
>
> Hmm.. Josh's original proposal did suggest batching events, but I nudged
> it towards individual events:
> https://github.com/w3c/performance-timeline/issues/1#issuecomment-59538916
>
> If we revert back to the batched model... how about:
>
>   performance.addEventListener('entries', function(events) {
>     events.forEach(function(event) {
>        // process event: event.entry.name, event.entry.entryType, etc...
>     }
>   });
>
> Does that look reasonable? What's the logic for batching these events?
>
> ig
>
>