Stream: git-wasmtime

Topic: wasmtime / issue #14506 Component import analysis can dra...


view this post on Zulip Wasmtime GitHub notifications bot (Oct 02 2026 at 23:17):

alexcrichton opened issue #14506:

This component takes ~4s to compile on main locally for me, but commenting out the two import analyses here drops the compile time to ~0.2s.

An LLM analysis, if useful, is:

<details>

Component compile time is O(N^2 K^2) in re-export chains (same-vmctx analysis)

Severity: low/medium (compile-time CPU DoS on untrusted components). Default
config; any compiler; Component::new / wasmtime compile.

Root cause

crates/environ/src/component/same_vmctx.rs (#14411): vmctx_key is
evaluated for every function import of every instantiation and walks the
full re-export chain back to the defining instance with no memoization; each
step calls Module::import_position (crates/environ/src/module.rs:542),
a linear scan of the module's imports.

The same pattern pre-exists in resolve_core_export
(crates/environ/src/component/translate.rs:1991, #14115, 2026-08-19); the
new analysis adds a second copy. perf splits time ~51%
resolve_core_export / ~48% same_vmctx::observe_instantiation.

Repro

Module M imports N functions and re-exports them all; the component
instantiates M K times in a chain, each instance fed the previous one. Each
extra instantiation costs a few bytes. gen_chain.py N K generates it.

input size wasmtime compile
100x100 0.03s
100x400 0.33-0.55s
chain-400x400.wat 16KB binary 4.8-6.2s
200x800 71KB text 6.75s
big.wasm (1000x1000) 41KB 281s, 93MB peak
target/release/wasmtime compile chain-400x400.wat -o /dev/null
target/release/wasmtime compile big.wasm -o /dev/null

Suggested fix

Compute each instance's import keys once in DFG order (arguments always come
from earlier instances) and cache per (instance, import); same for
resolve_core_export. Replace the linear import_position scan with a
precomputed map.

</details>

cc @fitzgen

view this post on Zulip Wasmtime GitHub notifications bot (Oct 02 2026 at 23:17):

alexcrichton added the cranelift:goal:compile-time label to Issue #14506.

view this post on Zulip Wasmtime GitHub notifications bot (Oct 02 2026 at 23:17):

alexcrichton added the wasm-proposal:component-model label to Issue #14506.

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

alexcrichton closed issue #14506:

This component takes ~4s to compile on main locally for me, but commenting out the two import analyses here drops the compile time to ~0.2s.

An LLM analysis, if useful, is:

<details>

Component compile time is O(N^2 K^2) in re-export chains (same-vmctx analysis)

Severity: low/medium (compile-time CPU DoS on untrusted components). Default
config; any compiler; Component::new / wasmtime compile.

Root cause

crates/environ/src/component/same_vmctx.rs (#14411): vmctx_key is
evaluated for every function import of every instantiation and walks the
full re-export chain back to the defining instance with no memoization; each
step calls Module::import_position (crates/environ/src/module.rs:542),
a linear scan of the module's imports.

The same pattern pre-exists in resolve_core_export
(crates/environ/src/component/translate.rs:1991, #14115, 2026-08-19); the
new analysis adds a second copy. perf splits time ~51%
resolve_core_export / ~48% same_vmctx::observe_instantiation.

Repro

Module M imports N functions and re-exports them all; the component
instantiates M K times in a chain, each instance fed the previous one. Each
extra instantiation costs a few bytes. gen_chain.py N K generates it.

input size wasmtime compile
100x100 0.03s
100x400 0.33-0.55s
chain-400x400.wat 16KB binary 4.8-6.2s
200x800 71KB text 6.75s
big.wasm (1000x1000) 41KB 281s, 93MB peak
target/release/wasmtime compile chain-400x400.wat -o /dev/null
target/release/wasmtime compile big.wasm -o /dev/null

Suggested fix

Compute each instance's import keys once in DFG order (arguments always come
from earlier instances) and cache per (instance, import); same for
resolve_core_export. Replace the linear import_position scan with a
precomputed map.

</details>

cc @fitzgen


Last updated: Oct 11 2026 at 04:10 UTC