Eli Perelman wrote:
> 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?
Right. The devtools can only show data coming from one process, and there's
no plan to aggregate data from different app/process.
So the aggregation needs to be done at the platform level or at the app level.
Whatever API and mechanism you choose, if you want the markers to show-up in
the devtools, the only thing you need is to call:
If it has a duration:
docShell->AddProfileTimelineMarker("aMarkerID", TRACING_INTERVAL_START);
docShell->AddProfileTimelineMarker("aMarkerID", TRACING_INTERVAL_END);
Or if it's one-time event:
docShell->AddProfileTimelineMarker("aMarkerID", TRACING_EVENT);
docShell being the top level docshell of the app.
> 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
-- Paul
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
