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.

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)

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

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.

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

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