The idea, at least for the devtools visualization, would be for markers and
measurements that occur in different processes to be displayed on the
existing timeline. For example, if I create a marker in the System app that
is linked to an action that occured in the Contacts app, that marker should
be displayed in the Contacts timeline. Likewise if I create a linked
measurement in verticalhome and System that is contextually bound to
another app, it should display as a duration in that app's timeline.

For performance testing, it's pretty much the same concept, but we need the
data to be compatible between processes. If an app creates a timestamp
using performance.now(), and the System does the same, there isn't
currently a mechanism that we can use to compare the deltas between the two
timestamps. Having a way to link markers will let us compare
high-resolution timestamps across processes.

Does that makes sense?

Thanks,

*Eli Perelman*
Software Engineer, Firefox OS

On Thu, Oct 16, 2014 at 5:35 AM, Ting-Yu Chou <[email protected]> wrote:

> Eli,
>
> I really like User Timing API, it indeed helps for things like bug 1063708
> and
> bug 1074783.
>
> But I am not sure I understand your idea correctly. As a user, when I add
> markers, I usally expect them to be shown on a single timeline, so what
> will
> linked markers help? I mean, for the use case you mentioned, what's the
> value
> linked markers offer more than unlinkd markers?
>
> Or will there be multiple timelines?
>
> Thanks,
> Ting
>
> ----- Original Message -----
> > From: "Eli Perelman" <[email protected]>
> > To: "dev-b2g" <[email protected]>
> > Sent: Wednesday, October 15, 2014 9:39:41 PM
> > Subject: [b2g] Performance marker linking proposal
> >
> > Hello,
> >
> > With the User Timing API [1], it will be possible for sites and
> applications
> > to create arbitrary markers in JavaScript to denote important moments in
> its
> > lifecycle.
> >
> > ```js
> > // Example: Dialer app denoting the call log is ready
> > performance.mark('callLogReady');
> > ```
> >
> > These markers are accessible using
> `performance.getEntriesByType('mark')`,
> > and each entry contains an object with metadata associated with the
> timing
> > of the marker.
> >
> > This API has not yet been implemented in Gecko [2], but is currently
> live in
> > Chrome and IE. In order to make this API more useful for performance
> > testing, I would like to propose an API available to the System app for
> > creating linked performance markers.
> >
> > As an example, I'll take the common application launch scenario. While
> using
> > the homescreen and the user taps an icon to launch an app, ideally it
> would
> > create a marker to denote the moment of user intent. Then in the System
> app,
> > another marker would be created to denote the moment of the
> instantiation of
> > the app window. Finally, the application itself would create markers
> > implying its own loading progress. The System app should have a mechanism
> > for tying all these markers together so we can report a timeline of the
> > entire interaction.
> >
> > There are many more scenarios for linking markers than this, but I hope
> this
> > conveys the idea. For even more value in performance testing though, I
> also
> > believe that the System app should receive events when markers are
> created.
> > This will enable us to use the proposed API at the correct moment to
> fetch
> > the linked marker data with relevant metadata to know for which context
> it
> > was generated against.
> >
> > Using these two mechanisms together would greatly improve the efficiency
> and
> > expand the functionality for Gaia to do performance testing and would
> pave
> > the way for more insightful developer tooling. I welcome any comments and
> > suggestions to get the ball rolling on this idea.
> >
> > [1] http://www.w3.org/TR/user-timing/
> > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=782751
> >
> > Thanks,
> >
> > Eli Perelman
> > Software Engineer, Firefox OS
> >
> > _______________________________________________
> > dev-b2g mailing list
> > [email protected]
> > https://lists.mozilla.org/listinfo/dev-b2g
> >
>
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to