Wasmtime GitHub notifications bot (Jun 07 2024 at 13:05): Wasmtime GitHub notifications bot (Jun 07 2024 at 13:05):yoshuawuyts opened issue #8757:
Feature
Enable wasmtime to output CPU profiles in the VS Code-compatible
.cpuprofileformat.Benefit
Right now wasmtime can take guest profiles using the
--profile=guestflag, but these profiles are stored in Firefox profiler's.jsonformat. VS Code can natively render CPU profiles, but only using the.cpuprofileformat. 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
--profileflag to language native toolchains. So that you could run e.g.cargo test --profile, or maybe even hit theprofilebutton 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
.cpuprofileformat. But since I believe the.cpuprofileis 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
Wasmtime GitHub notifications bot (Jun 07 2024 at 13:07):yoshuawuyts edited issue #8757:
Feature
Enable wasmtime to output CPU profiles in the VS Code-compatible
.cpuprofileformat.Benefit
Right now wasmtime can take guest profiles using the
--profile=guestflag, but these profiles are stored in Firefox profiler's.jsonformat. VS Code can natively render CPU profiles, but only using the.cpuprofileformat. 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
--profileflag to language native toolchains. So that you could run e.g.cargo test --profile, or maybe even hit theprofilebutton 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
.cpuprofileformat. But since I believe the.cpuprofileis 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
Wasmtime GitHub notifications bot (Jun 07 2024 at 13:10):yoshuawuyts edited issue #8757:
Feature
Enable wasmtime to output CPU profiles in the VS Code-compatible
.cpuprofileformat.Benefit
Right now wasmtime can take guest profiles using the
--profile=guestflag, but these profiles are stored in Firefox profiler's.jsonformat. VS Code can natively render CPU profiles, but only using the.cpuprofileformat. 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
--profileflag to language native toolchains. So that you could run e.g.cargo test --profile, or maybe even hit theprofilebutton 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
.cpuprofileformat. But since I believe the.cpuprofileis 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
Wasmtime GitHub notifications bot (Jun 07 2024 at 13:12):yoshuawuyts edited issue #8757:
Feature
Enable wasmtime to output CPU profiles in the VS Code-compatible
.cpuprofileformat.Benefit
Right now wasmtime can take guest profiles using the
--profile=guestflag, but these profiles are stored in Firefox profiler's.jsonformat. VS Code can natively render CPU profiles, but only using the.cpuprofileformat. 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
--profileflag to language native toolchains. So that you could run e.g.cargo test --profile, or maybe even hit theprofilebutton 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
.cpuprofileformat. But since I believe the.cpuprofileis 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
Wasmtime GitHub notifications bot (Jun 07 2024 at 13:13):yoshuawuyts edited issue #8757:
Feature
Enable wasmtime to output CPU profiles in the VS Code-compatible
.cpuprofileformat.Benefit
Right now wasmtime can take guest profiles using the
--profile=guestflag, but these profiles are stored in Firefox profiler's.jsonformat. VS Code can natively render CPU profiles, but only using the.cpuprofileformat. 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
--profileflag to language native toolchains. So that you could run e.g.cargo test --profile, or maybe even hit theprofilebutton 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
.cpuprofileformat. But since I believe the.cpuprofileis 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
Wasmtime GitHub notifications bot (Jun 07 2024 at 13:30):bjorn3 commented on issue #8757:
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)
Wasmtime GitHub notifications bot (Jun 07 2024 at 13:38):yoshuawuyts commented on issue #8757:
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.
Wasmtime GitHub notifications bot (Jun 07 2024 at 14:55):alexcrichton commented on issue #8757:
Even if we don't switch the default I think it's reasonable to support. The
--profileoption already supports--profile guest,other-path.json,10msand we could extend that to something like--profile guest-vscodeor--profile guest,vscodeor something like that.
Last updated: Nov 22 2024 at 17:03 UTC
