Stream: git-wasmtime

Topic: wasmtime / PR #13077 Add `wasmtime hot-blocks` subcommand

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 19:39):

fitzgen requested wasmtime-core-reviewers for a review on PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 19:39):

fitzgen requested pchickey for a review on PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 19:39):

fitzgen opened PR #13077 from fitzgen:wasmtime-hot-blocks to bytecodealliance:main:

This commit adds a new wasmtime hot-blocks subcommand that profiles Wasm
execution using perf and identifies the hottest basic blocks in the compiled
Wasm code.

Example output:

$ cargo run -- hot-blocks -F 999 -p 100 tests/all/cli_tests/fib.wat
`fib` :: block 0x16 :: 81.62% total samples

 [Samples]   [Assembly]                 [CLIF]                       [Wasm]
    14.07%   add     esi, 1             -                            -
    21.29%   lea     ecx, [rax + rdi]   v14 = iadd.i32 v13, v12      i32.add
    13.29%   mov     rdi, rax           "                            "
    17.64%   mov     rax, rcx           "                            "
    15.33%   jmp     0xe                jump block3(v18, v13, v14)   br $loop

`fib` :: block 0x0 :: 18.33% total samples

 [Samples]   [Assembly]         [CLIF]                     [Wasm]
    18.33%   cmp     esi, edx   brif v11, block2, block5   br_if $break
             jae     0x2a       "                          "

`wasm[0]::function[1]` :: block 0x37 :: 0.04% total samples

 [Samples]   [Assembly]       [CLIF]             [Wasm]
     0.04%   add     ebx, 1   -                  -
             jmp     0x6b     jump block3(v14)   br $loop

Depends on https://github.com/bytecodealliance/wasmtime/pull/13073

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 19:39):

fitzgen requested wasmtime-core-reviewers for a review on PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 19:39):

fitzgen requested cfallin for a review on PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 19:40):

fitzgen requested wasmtime-default-reviewers for a review on PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 20:21):

fitzgen updated PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 21:01):

cfallin submitted PR review:

This looks reasonable overall -- with my level of review on all of the output-parsing cod calibrated at "this is a useful tool for developers" rather than "production-ready robustness".

A thought below but otherwise I'm happy to see this in-tree for its usefulness. Thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 21:01):

cfallin created PR review comment:

This feels slightly brittle to me in that it's essentially re-serializing (un-parsing) (parts of) the command line for a subprocess: we may miss new options we add that we'd want to pass to the subprocess. I wonder if it would make sense to have a .to_cmdline() / .serialize() / ... method on the RunCommand?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 21:01):

cfallin created PR review comment:

Rather than manually baking in the invocation of Capstone here, could we reuse the innards of wasmtime objdump to get the disassembly? That keeps our logic and deps for disassembly to one place overall.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 22:05):

fitzgen updated PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 22:05):

fitzgen submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 22:05):

fitzgen created PR review comment:

Turns out that the Display impleemntations do this already, so I reused that.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 22:06):

fitzgen submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 22:06):

fitzgen created PR review comment:

Factored out the disassembly code from the objdump command into a new, shared module and used it in hot_blocks.rs.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 22:17):

fitzgen updated PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 13 2026 at 23:57):

github-actions[bot] added the label wasmtime:api on PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 14:29):

fitzgen requested cfallin for a review on PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 15:02):

alexcrichton submitted PR review:

Nice!

Stray thought on this: could debuginfo factor into this as well during rendering? For example at minimum this could print the hex offset in wasm which could then be passed to wasm-tools addr2line, but at most it could run addr2line here in-process and print some information. If it's not easy to add though probably not worth it

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 15:20):

cfallin submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 15:20):

cfallin submitted PR review:

This looks reasonable overall -- with my level of review on all of the output-parsing code calibrated at "this is a useful tool for developers" rather than "production-ready robustness".

A thought below but otherwise I'm happy to see this in-tree for its usefulness. Thanks!

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 15:51):

fitzgen commented on PR #13077:

Stray thought on this: could debuginfo factor into this as well during rendering? For example at minimum this could print the hex offset in wasm which could then be passed to wasm-tools addr2line, but at most it could run addr2line here in-process and print some information. If it's not easy to add though probably not worth it

Sure, I can investigate this in a follow up. Are you imagining, when we have debuginfo available, output that loks something like this?

 [Samples]   [Assembly]                 [CLIF]                       [Wasm]
    14.07%   add     esi, 1             -                            -
    21.29%   lea     ecx, [rax + rdi]   v14 = iadd.i32 v13, v12      0x12 fib fib.rs:12:4

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 15:53):

fitzgen commented on PR #13077:

Hm or maybe something like objdump's mixed source and asm disassembly? That way we could still see the actual Wasm instructions.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 15:53):

fitzgen added PR #13077 Add wasmtime hot-blocks subcommand to the merge queue.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 16:09):

alexcrichton commented on PR #13077:

I was just thinking of source locations for now, so no need to read files on disk and intermingle in source code just yet. What you sketched sounds reasoanble to me!

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 16:17):

github-merge-queue[bot] removed PR #13077 Add wasmtime hot-blocks subcommand from the merge queue.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 16:53):

fitzgen updated PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 16:53):

fitzgen has enabled auto merge for PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 17:06):

fitzgen added PR #13077 Add wasmtime hot-blocks subcommand to the merge queue.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 17:43):

fitzgen merged PR #13077.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 14 2026 at 17:43):

fitzgen removed PR #13077 Add wasmtime hot-blocks subcommand from the merge queue.

Last updated: May 03 2026 at 22:13 UTC