Re: Notification for new navigation timing entries

The use case I keep coming back to is conditional logic in the event, for
example, "I want to know when the page has been marked as loaded." Using
getEntriesByName:

```
performance.addEventListener('entries', function(event) {
  var fullyLoaded = performance.getEntriesByName('mark_fully_loaded',
'mark')[0];

  if (fullyLoaded) {
    // continue on...
  }
});
```

It will take reading the entries collection upon each invocation of this
event. Now everything is a game of tradeoffs obviously, so we either trade
deferring instantiation of the JS objects in the case that an entry may not
be needed, or we instantiate them every time for the case that they may be.
Possible array iteration in the first scenario, and none in the second is
also something to consider. I'm more inclined to believe that if an event
is bound, then an entry context is wanted, but this is just a guess.

I also understand the concern about the mass creation of events, which I
would want to avoid as well. What about creating individual events for the
distinct entry types, e.g. "onmark", "onmeasure", etc.?

Thoughts?

Thanks,

Eli Perelman

On Wed, Oct 22, 2014 at 8:35 PM, Nat Duca <nduca@google.com> wrote:

> 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
>>
>>
>