Re: Notification for new navigation timing entries

Neat scenario Eli! What about hasEntriesOfName() as fast form of
get*ByName()?

But as I think about it, this possibility of someone running a callback on
every microtask is actually still scarily big [5 microtasks per frame,
easily!]. Did we talk about making this more explicit in the api:
requestCallbackWhenEventOfNameIsAdded(name). The good part of this is we
can have events being added to the timeline and be sure that we're not
interfering with performance. Thats' a good thing to aspire to, I think.

The reason I'm big on performance is a unified timeline with things from
different sources is awesomely powerful for profiling and surfacing
critical performance information to our devs. The timelines in the latest
moz builds and chrome tracing show this.

But, since its super hard to take back apis once we let them out, we want
to keep the system's runtime overhead as low as possible always. That way
if we do want to surface something down the road we mostly have to concern
ourselves with "can we measure this in c++ fast enough and store it to a
fancy c++ coded buffer and only give it to the user when they do
getEntries." That is, we can monitor anything we feel is safe to monitor,
and feasible to monitor in c++. If we have script happening at too often a
rate, we're in this place of "every time we add one of these to the
timeline, some stupid popular <insert your favorite framework to pick on>
script runs and burns 1ms."

Good thing to think through: gc events. Not that i want this but its an
exemplar. But they're easy for us to buffer up in c++ but they happen
enough that if we were triggering c++->js transitions often, we might
decide we can't put them in the timeline to begin with.

On Wed, Oct 22, 2014 at 6:52 PM, Eli Perelman <eperelman@mozilla.com> wrote:

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