Re: Notification for new navigation timing entries

On 10/23/2014 01:28 AM, Nat Duca 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.

MutationObserver doesn't use any events.
Just a sequence of MutationRecords which are passed to the callback.


What is the reason why navigation timing entries notification should use microtasks and not tasks? Or actually, maybe it should
use animation frame ticks?



-Olli




>
> On Wed, Oct 22, 2014 at 2:49 PM, Ilya Grigorik <igrigorik@google.com <mailto:igrigorik@google.com>> wrote:
>
>     After some back and forth on GH, we've arrived at the following:
>
>     1) add "onentry" event handler to Performance interface
>     2) new PerformanceEntryEvent should be fired each time new event is added to timeline (nav+resource timing, frame timing, etc)
>          - each PEE event contains an "entry" attribute, which points to the source event
>
>     As a hands on example, this enables:
>
>        performance.addEventListener('entry', function(event) {
>          // process event: event.entry.name <http://event.entry.name>, event.entry.entryType, etc...
>        });
>
>     As a bonus, above behavior can be polyfilled, e.g...
>        var entry = performance.getEntriesByName('mark_fully_visible', 'mark');
>        var event = new PerformanceEntryEvent(entry);
>        performance.dispatchEvent(event);
>
>     ----
>
>     Thoughts, comments?
>
>     ig
>
>     On Thu, Oct 16, 2014 at 2:19 PM, Ilya Grigorik <igrigorik@google.com <mailto:igrigorik@google.com>> wrote:
>
>         On Wed, Oct 15, 2014 at 7:35 AM, Eli Perelman <eperelman@mozilla.com <mailto:eperelman@mozilla.com>> wrote:
>
>             Has anything actionable come from this thread yet? I certainly find value in receiving events for performance entries and annotating them
>             as well.
>
>
>         I think we reached rough consensus that it's a good idea... and we just need to draft and land the spec update.
>
>         I've opened a tracking bug: https://github.com/w3c/performance-timeline/issues/1
>
>         ig
>
>
>             On Fri, Feb 28, 2014 at 3:19 PM, Joshua Peek <josh@joshpeek.com <mailto:josh@joshpeek.com>> wrote:
>             >
>             > For user timings, we're already using a wrapper as you mentioned.
>             > However, I'd prefer to use the standard interface. Its also possible
>             > for libraries outside my control to set new marks that I'd like to
>             > report.
>             >
>             > New resource timing data is often outside of the user's control. New
>             > images and scripts can be appended dynamically.
>
>
>
>

Received on Tuesday, 9 December 2014 00:36:32 UTC