Wasmtime GitHub notifications bot (Jul 16 2026 at 12:19): Wasmtime GitHub notifications bot (Jul 16 2026 at 12:19):tschneidereit opened PR #13888 from tschneidereit:scope-tracking-opts to bytecodealliance:main:
Combined, the two contained commits improve call overhead for sync calls without borrows byt about 50%, from 65ns to 32ns, and immediately ready async calls without borrows by about 9%, from 117ns to 106. All numbers relative to #13887.
Wasmtime GitHub notifications bot (Jul 16 2026 at 12:19):tschneidereit added the label wasmtime on PR #13888.
Wasmtime GitHub notifications bot (Jul 16 2026 at 12:19):tschneidereit added the label performance on PR #13888.
Wasmtime GitHub notifications bot (Jul 16 2026 at 12:19):tschneidereit requested pchickey for a review on PR #13888.
Wasmtime GitHub notifications bot (Jul 16 2026 at 12:19):tschneidereit requested wasmtime-core-reviewers for a review on PR #13888.
Wasmtime GitHub notifications bot (Jul 16 2026 at 12:23):tschneidereit updated PR #13888.
Wasmtime GitHub notifications bot (Jul 16 2026 at 14:24):github-actions[bot] added the label wasmtime:api on PR #13888.
Wasmtime GitHub notifications bot (Jul 16 2026 at 17:06)::thumbs_up: pchickey submitted PR review.
Wasmtime GitHub notifications bot (Jul 16 2026 at 19:20):alexcrichton requested alexcrichton for a review on PR #13888.
Wasmtime GitHub notifications bot (Jul 16 2026 at 22:03):alexcrichton commented on PR #13888:
I've self-requested a review of myself here, this is something I'll want to sit down and think about for a bit as how it relates to the various bits of state-management this is skipping.
Wasmtime GitHub notifications bot (Jul 17 2026 at 17:01)::repeat: alexcrichton submitted PR review:
Hm ok personally I'm not quite comfortable landing this yet. I'd like to better understand what's being optimized here and how this is achieving that. It looks like this new
want_scope: booloption is serving double-duty where in concurrency_support-disabled builds it's avoiding a push/pop on a stack, and in all builds it's avoiding an invocation ofstore.current_scope_id()?. I've no doubt that avoiding the latter would likely yield a speed boost, but the former I find confusing to follow and would prefer to not add (and given that it seems to only affect concurrency_support-disabled builds it might be fine to remove).I'm in general wary of making the state machine/states/etc here more complex. Async is already complex enough and every new variant of "if X do Y else Z" explodes the state space 2x that needs to be considered. If this is isolated to just a small piece of code I think that's fine, but this is pretty pervasive affecting core data structures.
This is why I'd like to better understand what this is optimizing and how it's optimizing it. I don't have a great handle on that as-is and am unable to conclude if this is the best way to avoid the overhead or not.
Last updated: Jul 29 2026 at 05:03 UTC