Firefox profiler UI enhancements

[xoofx]

There are several UI enhancements that would be worth to have in ultra.

For instance, many existing PRs done by @parttimenerd are basic stuffs that we really need to have in Firefox Profiler to make it usable:

• Implement Method Table view #4227 : This one provides a method table view that is quite common in profiler and would help to investigate issues for a particular method. Today, it's not possible to have such information, which is quite frustrating.
• Add sort buttons (▲/▼) to TreeView columns #4265 especially interesting for markers with a duration (e.g. JitCompile or GCEvent in ultra)
• Implement marker based stack strategies #4293

Additionally, there are several other enhancements that I'm looking for:

• Styling markers: today, marker styles are hardcoded in such a way that I have to hack around and use an existing marker name in order to display markers in different colors and positions. We should be able to provide our own style as part of the marker schema.
• Show aggregate duration for markers: If a marker has a duration, it is interesting for a range to show the aggregate duration of markers. It could be shown when we select a row in the marker chart and marker table (when filtering)
• Custom counters track: Counter tracks are also hardcoded to only the supported following category Memory, power, Bandwidth. This is very limiting. For example, I would like to display the memory for each GC generation but it seems that cannot achieve this with existing counter tracks.

[julienw]

Thanks for the helpful list and sharing your expectations!

I wanted to mention 2 things related to your list:

Custom counters track

We don't support that at the moment. However we support custom graphs based on markers. The documentation is pretty sparse about that but you can see the type on the marker schema in https://github.com/firefox-devtools/profiler/blob/5b553306704847bd1367c535dc5d721dc119fc29/src/types/markers.js#L114-L119

Aggregate

@padenot worked on an extension for the profiler called fouineur.
With that you can graph values coming from any marker (not just the ones configured in the schema) including running some computations on them (see the processing primitives).

I hope you'll find that useful!

[xoofx]

Thanks for the helpful list and sharing your expectations!

👍

Custom counters track

We don't support that at the moment. However we support custom graphs based on markers. The documentation is pretty sparse about that but you can see the type on the marker schema in https://github.com/firefox-devtools/profiler/blob/5b553306704847bd1367c535dc5d721dc119fc29/src/types/markers.js#L114-L119

Thanks, yep, I'm using these already. The small annoyance is that these graphs are associated with a thread. In the case I'm currently using them, it's ok because I would like to show allocations per thread. But in other scenarios (total memory), I would prefer to have them "global", but don't think I can specify that today.

Also, a related annoyance is that counters graphs are put at the very bottom of the tracks. If you have multiple counters associated to a thread, they become hard to find. Similarly, I would prefer to have an "order" property on threads and counters tracks so that I could display/group them the way I want in the UI, instead on relying on the name of the thread track (that are still separated from counters).

Aggregate

@padenot worked on an extension for the profiler called fouineur. With that you can graph values coming from any marker (not just the ones configured in the schema) including running some computations on them (see the processing primitives).

Yeah, it could be solution, but plenty of folks are not necessarily using Firefox itself when browsing, or even willing to install an extension so it would be easier with a built-in solution 🙂

But I'll keep digging on solutions. A small fork on my side could be a solution in the interim.

[xoofx]

instead on relying on the name of the thread track (that are still separated from counters).

For example, to workaround this (partially, because counters are ordered separately), I had to add a "threadindex" before the name of the thread to enforce an order. The order that I provide by default is total CPU in descending order so that you get the most interesting threads at the top, which greatly improves readability.

ultra/src/Ultra.Core/EtwConverterToFirefox.cs

Line 310 in 7f828cd

var threadName = $"{threadIndex} - {threadBaseName}";