alexcrichton opened issue #14506:
This component takes ~4s to compile on
mainlocally 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)
- Commit: 249bdf8fca (main2), audited 2026-10-02
- Platform: Linux 7.0.0-31-generic x86_64
- Auditor: Claude Opus 5.5 (claude-opus-5-5)
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_keyis
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 callsModule::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.perfsplits 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 Kgenerates it.
input size wasmtime compile100x100 0.03s 100x400 0.33-0.55s chain-400x400.wat16KB 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/nullSuggested 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 linearimport_positionscan with a
precomputed map.</details>
cc @fitzgen
alexcrichton added the cranelift:goal:compile-time label to Issue #14506.
alexcrichton added the wasm-proposal:component-model label to Issue #14506.
alexcrichton closed issue #14506:
This component takes ~4s to compile on
mainlocally 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)
- Commit: 249bdf8fca (main2), audited 2026-10-02
- Platform: Linux 7.0.0-31-generic x86_64
- Auditor: Claude Opus 5.5 (claude-opus-5-5)
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_keyis
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 callsModule::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.perfsplits 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 Kgenerates it.
input size wasmtime compile100x100 0.03s 100x400 0.33-0.55s chain-400x400.wat16KB 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/nullSuggested 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 linearimport_positionscan with a
precomputed map.</details>
cc @fitzgen
Last updated: Oct 11 2026 at 04:10 UTC