Open larseggert opened 4 months ago
Ah yes, we should update our documentation to point to samply
instead:
Use samply import perf.data
and it will open the Firefox profiler with the converted profile, and overall be much faster than running perf script
first.
Dragging the perf.data
file itself into the Firefox Profiler isn't really something we can make work; the perf.data
file doesn't carry any symbol information. The symbols come from other files on the file system.
I'm not sure if samply
works for us, since we run perf
in CI and then export the data as CI artifacts, for download and analysis on local machines.
Cool, can you give me a link to the script that runs perf as part of your CI? I'm curious.
If the symbols are only on the CI machine, then the symbolication has to happen on the CI machine. At the moment samply does not have a way to put the symbols into the generated profile.json
; the symbols are added once the profile has been loaded by the front-end, with separate symbolication requests to the local samply server.
If the symbols are also uploaded on some kind of symbol server, then theoretically you could generate unsymbolicated profile.json files in CI (using samply import perf.data -o profile.json --save-only
and symbolicate them on demand when developers look at the collected files. But this would not be a very ergonomic solution.
So I think for now you'll need to keep using perf script
until I implement upfront symbolication in samply.
Cool, can you give me a link to the script that runs perf as part of your CI? I'm curious.
Very cool! In case others are curious, here's an example profile I got from one of the zip files on one of the PRs: https://share.firefox.dev/3wvM5uR
It's a bit annoying that one needs to convert a perf trace with
perf script
before it can be loaded into the profiler, because that explodes the file size by an order of magnitude.┆Issue is synchronized with this Jira Task