Wasmtime GitHub notifications bot (Mar 25 2026 at 08:54): Wasmtime GitHub notifications bot (Mar 25 2026 at 08:54):JoonasBjork opened issue #12836:
Improvement
Wasmtime v43
Config::new()enablesconcurrency_supportoption by default as per the config . This configuration is shipped inwasmtime-v43.0.0-aarch64-macos(tested). In practice, this causes synchronous function calls to have overhead even in Component model binaries that do not use asynchronous features. The culprit seems to be that the FACT module ends up running this code on every synchronous cross-Component function invocation.After testing a program that repeatedly invokes an empty function over Component boundaries with and without the command line option
-W concurrency-support=n, I can see a 50x-100x increase in latency withconcurrency-supportenabled.Unfortunately I cannot share code.
Benefit
Disabling the option by default has a significant performance benefits for synchronous Component-model applications that do not need async features. The option should be set only when the used Component needs asynchronous features.
Implementation
Disabling the option in the config by default. Prompting users that want to use async components to enable the feature.
Wasmtime GitHub notifications bot (Mar 25 2026 at 14:03):cfallin commented on issue #12836:
Thanks for filing an issue!
A number of us have expressed concern about the overhead of the checks on cross-task invocations; #12311 tracks some possible optimizations but ideally it'd be great to see if we can remove the need for these dynamic checks as much as possible from the spec. This Zulip thread shows a bunch of discussion about this as well.
I believe this is quite an urgent issue, it adds real cost to any component composition use-case, and probably needs to feed back pressure to the spec to question at least the "may-enter checks" and "may-leave checks" somewhat. I still don't fully understand the concrete motivation/use-cases for these dynamic checks (I get the "reentrancy can lead to subtle bugs" for may-enter, but that doesn't break the sandbox and we don't add high dynamic cost for other kinds of bug-catchers like e.g. ASan; may-leave is I believe motivated by callbacks for malloc only; may-block should be needed only in async cases and also maybe could be pushed to the runtime itself rather than the adapter fastpath?). (cc @lukewagner for spec concerns)
Wasmtime GitHub notifications bot (Mar 30 2026 at 13:55):alexcrichton commented on issue #12836:
As has been commented here already, this is an issue of defaults, at least in my opinion. I agree that https://github.com/bytecodealliance/wasmtime/issues/12311 tracks the work necessary to resolve the performance issues here.
There's a lot more information on #12311 as to the background here as to why this is here, but the basic tl;dr; is that component<->component calls are semantically different with asynchronous things in the mix, thus some extra instrumentation is necessary. Wasmtime's current implementation is far from optimal, and it's well understood that this isn't great and needs to be improved. Historically we've been working towards a world where this is a problem, vs never shipping p3 due to delays and losing momentum entirely.
Personally I think that this issue should be closed in favor of a combination of #12311 plus an optional issue upstream on the component-model itself if you'd like @cfallin. I personally believe that the current defaults are correct (async things on-by-default) as that matches the direction of the spec. I understand your concerns though @JoonasBjork about how this results in surprisingly performance degredation in component<->component calls, and I see issues like this as further pressure for us to implement the optimizations in #12311, for example.
probably needs to feed back pressure to the spec to question at least the "may-enter checks" and "may-leave checks" somewhat
FWIW these checks have effectively nothing to do with the performance degredation. We've discussed at the spec-level quite a lot about how to optimize these checks and the need to optimize to more-or-less exaclty zero instructions in "the stars aligned" cases (e.g. what host builtins would exercise). I'm not personally aware of anything else to do at the spec level other than "someone needs to work on #12311 and take the results to the spec".
Wasmtime GitHub notifications bot (Mar 30 2026 at 13:56):alexcrichton added the wasm-proposal:component-model-async label to Issue #12836.
Wasmtime GitHub notifications bot (Mar 30 2026 at 14:44):cfallin closed issue #12836:
Improvement
Wasmtime v43
Config::new()enablesconcurrency_supportoption by default as per the config . This configuration is shipped inwasmtime-v43.0.0-aarch64-macos(tested). In practice, this causes synchronous function calls to have overhead even in Component model binaries that do not use asynchronous features. The culprit seems to be that the FACT module ends up running this code on every synchronous cross-Component function invocation.After testing a program that repeatedly invokes an empty function over Component boundaries with and without the command line option
-W concurrency-support=n, I can see a 50x-100x increase in latency withconcurrency-supportenabled.Unfortunately I cannot share code.
Benefit
Disabling the option by default has a significant performance benefits for synchronous Component-model applications that do not need async features. The option should be set only when the used Component needs asynchronous features.
Implementation
Disabling the option in the config by default. Prompting users that want to use async components to enable the feature.
Wasmtime GitHub notifications bot (Mar 30 2026 at 14:44):cfallin commented on issue #12836:
FWIW these checks have effectively nothing to do with the performance degredation. We've discussed at the spec-level quite a lot about how to optimize these checks and the need to optimize to more-or-less exaclty zero instructions in "the stars aligned" cases (e.g. what host builtins would exercise). I'm not personally aware of anything else to do at the spec level other than "someone needs to work on https://github.com/bytecodealliance/wasmtime/issues/12311 and take the results to the spec".
Sorry, yeah, I guess I'm bucketing the three distinct kinds of checks in my head as "things that get in the way of direct calls" -- may-enter and may-leave together with (this issue's) async state. Agreed that async state tracking is semantically fundamental as long as tasks and task management on async calls exist. There's webassembly/component-model#626 where the topic of minimizing spec-mandated Stuff for cross-component accessors is being discussed, so I'm happy to see this closed in favor of that issue (with the Wasmtime-specific part here a duplicate of #12311, agreed).
Last updated: Apr 12 2026 at 23:10 UTC