Skip to content

Split current_thread into an inline fast path and a cold slow path - #13887

Merged
alexcrichton merged 1 commit into
bytecodealliance:mainfrom
tschneidereit:current-thread-fast-path
Jul 16, 2026
Merged

Split current_thread into an inline fast path and a cold slow path#13887
alexcrichton merged 1 commit into
bytecodealliance:mainfrom
tschneidereit:current-thread-fast-path

Conversation

@tschneidereit

Copy link
Copy Markdown
Member

Splitting current_thread into an #[inline] fast path plus #[cold] outlined deferred-promotion slow path reduces call overhead by about 20% (measured in a Linux VM on an M5 Max MBP): sync calls go from about 83ns to about 65ns, immediately ready async calls from 142ns to 117ns.

@tschneidereit
tschneidereit requested a review from a team as a code owner July 16, 2026 11:51
@tschneidereit
tschneidereit removed the request for review from a team July 16, 2026 11:51
@tschneidereit tschneidereit added the wasmtime Issues about wasmtime that don't fall into another label label Jul 16, 2026
@tschneidereit
tschneidereit requested a review from pchickey July 16, 2026 11:51
Splitting current_thread into an #[inline] fast path plus #[cold]
outlined deferred-promotion slow path reduces call overhead by
about 20% (measured in a Linux VM on an M5 Max MBP): sync calls go
from about 83ns to about 65ns, immediately ready async calls from
142ns to 117ns.
@tschneidereit
tschneidereit force-pushed the current-thread-fast-path branch from 13a065d to 0e5a755 Compare July 16, 2026 11:52
tschneidereit added a commit to tschneidereit/wasmtime that referenced this pull request Jul 16, 2026
Precompute `TypeFunc::contains_borrow` at compile time and use it in
the hostcall entrypoint to skip `CallContext` scope push/pop and
`validate_scope_exit` when lending is statically impossible.

Relative to bytecodealliance#13887, this reduces call overhead by
about 29% for sync calls, and about 9% for async calls (both measured
in a Linux VM on an M5 Max MBP): sync calls go from about 65ns to about
46ns, immediately ready async calls from 117ns to 106ns.

I'm not entirely sure why the win is so much less for async calls, but
there are more wins in future commits.
@github-actions github-actions Bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Jul 16, 2026
@alexcrichton
alexcrichton added this pull request to the merge queue Jul 16, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jul 16, 2026
@alexcrichton
alexcrichton added this pull request to the merge queue Jul 16, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jul 16, 2026
@alexcrichton
alexcrichton added this pull request to the merge queue Jul 16, 2026
@github-merge-queue
github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jul 16, 2026
@alexcrichton
alexcrichton added this pull request to the merge queue Jul 16, 2026
Merged via the queue into bytecodealliance:main with commit cc00440 Jul 16, 2026
53 checks passed
yagehu pushed a commit to yagehu/wasmtime-x that referenced this pull request Jul 26, 2026
…ytecodealliance#13887)

Splitting current_thread into an #[inline] fast path plus #[cold]
outlined deferred-promotion slow path reduces call overhead by
about 20% (measured in a Linux VM on an M5 Max MBP): sync calls go
from about 83ns to about 65ns, immediately ready async calls from
142ns to 117ns.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime Issues about wasmtime that don't fall into another label

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants