1104202 - Show console markers in timeline before timeEnd is called

Status: RESOLVED WONTFIX

(DevTools :: Performance Tools (Profiler/Timeline), enhancement, P3)

Description

[Tom Tromey :tromey]

I was playing with Console.time and Console.timeEnd.  The timeline
marker doesn't show up until the .timeEnd call -- but if you know
what the underlying code is doing (i.e., you're expecting the marker)
and if there is a long delay between the two calls, then it feels
a bit strange.  If you stop recording too soon, you might not even
see the console marker at all.  So, it might be nicer to show some
indication of the .time call when it happens, say with a box that
keeps extending in the display until the corresponding .timeEnd call.

Comment 1

[Jordan Santell [:jsantell] [@jsantell]]

Before we add an easy way for others to tag platform code with timeline markers (bug 1145247), we should think about scenarios like this one, that will require two separate ProfileTimelineMarkers. On the front end, we can either specify what marker types require two markers, or have these markers only have a start or an end, with some way to compare them on the front (to terminate the line inbetween, for example)

Comment 2

[Victor Porof [:vporof][:vp]]

Moving into the Profiler component. Filter on GUTHRIE'S WAVY CAKES.

Comment 3

[Jordan Santell [:jsantell] [@jsantell]]

2 ways to do this:

Use a new TracingMetadata object like TRACING_TIMESTAMP_START and TRACING_TIMESTAMP_END, each emitting their own markers, rather than grouping them up in start/end pairs, or we can do this for all markers, but I don't think many markers benefit from having a start and an end marker, other than long running things, like time/timeEnd.

Comment 4

[Jordan Santell [:jsantell] [@jsantell]]

I don't think this is hard at all, we just need to add it to the front end's marker declaration, and that shouldn't get more complex until we have all our marker stuff solid. Also not incredibly important, IMO, after more dogfooding

Comment 5

[Greg Tatum [:gregtatum] (REO Fx132)]

This is no longer valid with Bug 1408124, as we are moving away from the streaming data approach.