1849974 - [meta] Export JavaScript Tracer data to the gecko profiler frontend

Status: NEW

(DevTools :: General, enhancement)

Description

[Nicolas Chevobbe [:nchevobbe]]

This would help developer share the tracer and investigate issues, similarly to performance profiles.

The WebCompat team would find this quite helpful, and the Profiler team told us it would be quite simple to consume such file.

Comment 1

[Alexandre Poirot [:ochameau]]

I've been suggested by Julien to look at:
https://github.com/firefox-devtools/profiler/blob/17c4918daba1c2c4ed5f973b748009302e04fc5a/src/profile-logic/import/chrome.js#L487
and:
https://github.com/firefox-devtools/profiler/blob/main/src/profile-logic/data-structures.js
to learn how to craft a profiler's profile.

Otherwise, on the tracer side, we can see the type of data we get to qualify a frame:
https://searchfox.org/mozilla-central/rev/4e22b886bbd4c274f268c4a285ab7da00e95c99b/devtools/server/tracer/tracer.jsm#236-253
script.source.url will be the url of the js file running
and lineNumber / columnNumber the location of the frame that just ran.
I imagine it should be already enough to compute a profile?
The tracer is per thread, so we wouldn't be able to easily compute a multi-thread record.
At least, we should try to generated a mono-thread record as a first step.

Comment 2

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1849974 - [devtools] Template for adding JS tracing via profiler records.

I tweaked the pref so that tracing is enabled by default and automatically set to record to the profiler.
The tracer can be toggled on/off via Ctrl+Shift+5 or via the bold round icon on top right of the debugger.

Comment 3

[Alexandre Poirot [:ochameau]]

Dropping some notes before I forget about this.

In order to open sources from the call/flame chart, we could tweak the Open *filename* context menu
so that, if we are on a JS source, and this is a tracer record, we could try opening the debugger on that file URL and line/column.

The context menu is implemented over here:
https://github.com/firefox-devtools/profiler/blob/771ea45886455fb4048e8abb32bc8422f2bd3252/src/components/shared/CallNodeContextMenu.js#L542-L553

We may make it send a message to the chrome codebase like this:
https://github.com/firefox-devtools/profiler/blob/771ea45886455fb4048e8abb32bc8422f2bd3252/src/app-logic/web-channel.js#L112C1-L118

Message which is received by the chrome code over there:
https://searchfox.org/mozilla-central/rev/1f5d04fed3631f97a84b589429419b83342d7c9a/devtools/client/performance-new/shared/background.jsm.js#720

While the overall feature sounds trivial, it is actually challenging for two reasons:

• The debugger only works against "active" JavaScript sources. i.e. JS fils which are currently loaded in the debugged page.
• The profiler is opened in a new tab. The active devtools debugging the profiled page are on the profiled tab.

Because of these two constraints, it means that we would either have to:

• lookup for devtools opened against the tab we recorded traces for and switch to that tab and open the source from that tab's debugger.
• do the same, but instead of moving to the tab, we would make the devtools move to the profiler tab (we do some similar magic for debugging popups...)
• revisit the debugger architecture so that it can open URL of modules which are not loaded in the debugged page. This would be a significant refactoring for the debugger frontend. This may also be imperfect or require some additional work to support sourcemapped code correctly.
• display the profiler page within a DevTools panel, so that we stay on the same tab and there is a strong connection between the profile page and its related active DevTools session. Sounds complex as well.

All these options would only help seeing sources when opening the profile while the debugged page is still opened with its devtools still attached.
These options have the benefit of allowing to use the Debugger and still set breakpoint to resume the investigations.

Another completely different direction would be to work on the profiler frontend to allow loading the JavaScript file content.
But this would disallow easily navigating between trace records and the debugger.
The main advantage of this option is that it would help sharing the traces, but it is still unclear how to ensure showing the right source text content.

Comment 4

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

Attachment: WIP: Bug 1849974 - WIP: Add profiler logging method to JS tracer

Comment 5

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

The patch above is the current working prototype for the profiler importer. It currently opens up the profiler UI and sends the profile object to our frontend. It lacks the ability of opening the source code or correct sample durations.
Here's an example profile: https://share.firefox.dev/45unxhg
Unfortunately, I don't have enough bandwidth to improve it furter in the near future.

Comment 6

[Alexandre Poirot [:ochameau]]

One issue with the current patch is the lack of data in resourceTable, it should be populated in order to see more information about the location of each frame which would then use resourceIndex to refer to the related source.
This should help display the popup with source url/line/column information in the perf UI.

Comment 7

[Nazım Can Altınova [:canova][:canaltinova on phabricator]]

This converter produces gecko profile format not the processed profile format. Gecko profile format doesn't include a resource table. We add this table during the processing phase. There must be another bug that disallows this extraction in the code. I'm actually adding the line and column numbers in the converter but there might be something missing.

Comment 8

[Phabricator Automation]

Comment on attachment 9357620 [details]
WIP: Bug 1849974 - WIP: Add profiler logging method to JS tracer

Revision D190576 was moved to bug 1867599. Setting attachment 9357620 [details] to obsolete.