James Sturtevant (Jan 09 2025 at 22:56): James Sturtevant (Jan 09 2025 at 22:56):I am trying to reduce copies of data in the c# wit-bindgen (https://github.com/bytecodealliance/wit-bindgen/issues/1080) and make sure we aren't leaking memory (https://github.com/bytecodealliance/wit-bindgen/issues/1116) after calls to the host. I would like to verify that the changes did make some improvements.
Is there a way to profile the memory usage of a component with wasmtime? I was looking into https://docs.wasmtime.dev/examples-profiling.html but these mostly seem focused on cpu related scenarios.
Alex Crichton (Jan 09 2025 at 23:04):currently the only way to do this without extra instrumentation is to look at the final heap size which you can track via StoreLimits and isn't accessible via the CLI. (or at least not that I can remember). Otherwise tracking this would require instrumentation on the wasm side I think (and I'm not aware of anything easily/robustly available in this regard)
Ralph (Jan 10 2025 at 08:57):time to find a good location, make an issue, and eventually make this possible, @James Sturtevant :-P
James Sturtevant (Jan 10 2025 at 17:41):Happy to create an issue, Would wasmtime be the right place? I don't really know enough as two where the correct place is to place the hooks to make this possible.
currently the only way to do this without extra instrumentation
In wasmtime? or somewhere else?
instrumentation on the wasm side I think (and I'm not aware of anything easily/robustly available in this regard)
so the component would track this? or something else?
Alex Crichton (Jan 10 2025 at 17:56):For the wasmtime CLI itself we could have an issue for something like --print-max-memory-at-the-end-of-execution or something like that which prints out how many bytes the execution consumed at its maximum. I'll warn you though that this is quite coarse where it's in multiples of 64k so it's unlikely to help much in terms of tracking down leaks or proving reduced memory usage.
Otherwise having something closer to valgrind is much more intrusive to the wasm module itself and would necessarily have to make lots of assumptions. For example it would have to assume that malloc and free are exclusively used to allocate memory, it would assume that there's a name section to identify where those functions are, and then it would have to assume that they have a particular signature. Even then injecting instrumentation into a module after-the-fact is not easy -- one option is wizer-style where you take a module and generate a module with instrumentation, and another option is wmemcheck-style where it's baked directly into the host itself.
For the latter choice here, a more accurate per-module view of fine-grained memory usage, I'm not sure where such an issue would reside as it's a substantial new project that might even warrant its own repository
Alex Crichton (Jan 10 2025 at 17:56):James Sturtevant said:
Happy to create an issue, Would wasmtime be the right place? I don't really know enough as two where the correct place is to place the hooks to make this possible.
currently the only way to do this without extra instrumentation
In wasmtime? or somewhere else?
yes, probably in the wasmtime CLI here because the crate itself already has support
Alex Crichton (Jan 10 2025 at 17:57):instrumentation on the wasm side I think (and I'm not aware of anything easily/robustly available in this regard)
so the component would track this? or something else?
yeah that's the rough idea, the component language runtime itself would have support ideally for tracking this sort of statistic
Last updated: Jan 24 2025 at 00:11 UTC