Skip to content

wasmtime: Cache VMFuncRef in component::Func - #14189

Open
adamrk wants to merge 2 commits into
bytecodealliance:mainfrom
adamrk:cache-component-funcref
Open

wasmtime: Cache VMFuncRef in component::Func#14189
adamrk wants to merge 2 commits into
bytecodealliance:mainfrom
adamrk:cache-component-funcref

Conversation

@adamrk

@adamrk adamrk commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

A core Func caches a raw pointer to its VMFuncRef, but a
component::Func rederives the pointer on ever call and this
contributes to host -> wasm component function calls having
significantly higher overhead than core function calls (even concurrency
support disabled).

This PR caches the VMFuncRef for component::Func in the same it is
currently done for core Func. The VMFuncRef for the associated
post_return call is also cached along with Some additional metadata.

These are my benchmark results for the impact on nop calls with no
arguments or return values:

Before change:

| Call type                         | Latency |
-----------------------------------------------
| core                              |   35 ns |
| component (concurrency disabled)  |  300 ns |
| component (concurrency enabled)   |  800 ns |

After change:

| Call type                         | Latency |
-----------------------------------------------
| core                              |   35 ns |
| component (concurrency disabled)  |  140 ns |
| component (concurrency enabled)   |  600 ns |

The bencmarks run are:

cargo bench --bench call -- --exact "sync/no-hook/core - host-to-wasm - typed - nop"
cargo bench --bench call -- --exact "no-concurrent/sync/no-hook/component - host-to-wasm - typed - nop"
cargo bench --bench call -- --exact "concurrent/sync/no-hook/component - host-to-wasm - typed - nop"

A separate commit also modifies the call benchmark to allow running component calls without concurrency support.

adamrk added 2 commits August 21, 2026 18:50
A core `Func` caches a raw pointer to its `VMFuncRef`, but a
`component::Func` rederives the pointer on ever call and this
contributes to host -> wasm component function calls having
significantly higher overhead than core function calls (even concurrency
support disabled).

This PR caches the `VMFuncRef` for `component::Func` in the same it is
currently done for core `Func`. The `VMFuncRef` for the associated
`post_return` call is also cached along with Some additional metadata.

These are my benchmark results for the impact on nop calls with no
arguments or return values:

Before change:

| Call type                         | Latency |
-----------------------------------------------
| core                              |   35 ns |
| component (concurrency disabled)  |  300 ns |
| component (concurrency enabled)   |  800 ns |

After change:

| Call type                         | Latency |
-----------------------------------------------
| core                              |   35 ns |
| component (concurrency disabled)  |  140 ns |
| component (concurrency enabled)   |  600 ns |

The bencmarks run are:
```
cargo bench --bench call -- --exact "sync/no-hook/core - host-to-wasm - typed - nop"
cargo bench --bench call -- --exact "no-concurrent/sync/no-hook/component - host-to-wasm - typed - nop"
cargo bench --bench call -- --exact "concurrent/sync/no-hook/component - host-to-wasm - typed - nop"
```
@adamrk
adamrk requested review from a team as code owners August 21, 2026 19:00
@adamrk
adamrk requested review from alexcrichton and pchickey and removed request for a team August 21, 2026 19:00
@github-actions github-actions Bot added wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:c-api Issues pertaining to the C API. labels Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wasmtime:api Related to the API of the `wasmtime` crate itself wasmtime:c-api Issues pertaining to the C API.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant