firefox-devtools / firefox-devtools/profiler

Consider adding an option to load profiles in CLI using samply's symbolication server

Open
#6,052 2 comments 0 reactions 0 assignees View on GitHub
cli epic-fp-1415
Dominant language
TypeScript
Stars
1.5k
Forks
491
Avg merge
3d 46m
Merged PRs (30d)
27

Description

Currently it's possible to do something like:
- Record a profile using `samply record --save-only`
- Load a profile using `profiler-cli`

But this doesn't give us the ability to use samply's symbolication server for symbolication and the assembly view. So there is a better way:

- Record a profile using `samply record`
- Keep its symbol server alive (or alternative would be `samply record --save-only` + `samply load`)
- And then while loading the profile in the cli, make sure to include the profile link that includes the symbol server path or pass `--symbol-server ` to the cli.
- **Note:** While I was writing this issue I noticed that we actually have a bug here! I filed #6050 and fixing it in #6051.

This works(-ish, due to the bug I mentioned above), but it's not the best UX. Ideally we should reduce the amount of friction of "profiling + analysis" workflows.

There are a few competing ideas to do this:

1. Add something like `profiler-cli samply record ...` which CLI calls samply to record and keeps the server alive until the analysis session is dead.
2. Add something like `profiler-cli load --with-samply `, which does `samply load` internally. So we can split the samply recording and the analysis parts into two concrete calls with `samply record --save-only` + cli. During the profile loading, profiler-cli would still hand it over to the samply for loading so it can start the symbol server.
3. Add something like `--with-profiler-cli` to `samply record` so it loads the profile after recording. But this seems like more effort and probably not the best UX either.

It feels like 1st idea is the best in terms of least friction. But I'm not so sure about passing `samply record` arguments to samply, it feels a bit messy. On the other hand, I think 2nd is a little more friction compared to 1, but probably less messy.

┆Issue is synchronized with this [Jira Task](https://mozilla-hub.atlassian.net/browse/FP-1309)

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.