Write --profile output using the .cpuprofile format in Wasmtime

[yoshuawuyts]

Feature

Enable wasmtime to output CPU profiles in the VS Code-compatible .cpuprofile format.

Benefit

Right now wasmtime can take guest profiles using the --profile=guest flag, but these profiles are stored in Firefox profiler's .json format. VS Code can natively render CPU profiles, but only using the .cpuprofile format. This is a JSON-based format, which shouldn't be too different from Wasmtime's existing output - but it would be neat if Wasmtime profiling support directly integrated with VS Code.

The flow I have in mind here is that we would add support for some --profile flag to language native toolchains. So that you could run e.g. cargo test --profile, or maybe even hit the profile button in VS Code - and then that outputs a performance profile which can be directly visualized in VS Code like so:

Implementation

Ideally we'd just switch over the existing profile format to .cpuprofile. That seems better than adding additional config - and I believe the Firefox profiler can already load those. I also don't think there is any loss of information if we do that?

If we can't do that, adding a flag could be another option. But it seems better to not add more config if we can help it. I think this should mostly just be a different way we encode the same information, so I imagine the change here should be fairly self-contained within Wasmtime.

Alternatives

The main alternative here would be to handle this in the language-native tooling, taking the existing output and rewriting it to the .cpuprofile format. But since I believe the .cpuprofile is equivalent to what Wasmtime outputs already, and also already appears to be supported by the Firefox profiler, it might be better to make this change directly in Wasmtime.

References

• .cpuprofile schema (Chrome devtools)
• JS .cpuprofile reference schema
• analyzing profiles in VS Code (VS Code docs)
• firefox profiler

[bjorn3]

It is not clear to me how the cpuprofile format would represent profiling multiple threads at the same time. I also can't find anything to encode events/markers (instants in time where something happened like the exact moment an http request was received by wasi-http)

[yoshuawuyts]

Ooff yeahh; what I wrote above includes this load-bearing sentence:

I also don't think there is any loss of information if we do that?

Completely agreed that if we in fact lose information by switching to .cpuprofile, then yeah we shouldn't switch over the base wasmtime output. There could potentially be value in integrating it with language-native tooling. But that's beyond the scope of this issue.

[alexcrichton]

Even if we don't switch the default I think it's reasonable to support. The --profile option already supports --profile guest,other-path.json,10ms and we could extend that to something like --profile guest-vscode or --profile guest,vscode or something like that.