Joel Dice (Mar 20 2025 at 13:56): Joel Dice (Mar 20 2025 at 13:56):A component, according to my understanding, is a module accompanied by an embedded but explicit interface definition which was provided as WIT
A component can be more than just a single module and an interface definition: it can contain an arbitrary number of modules and subcomponents (each with its own modules), plus directives which instantiate those modules and subcomponents, hooking up imports and exports in various combinations.
Hypothetically, one could write a tool which extracts all the modules from a component, optimizes them using wasm-opt, and then re-inserts those modules back into the component. No such tool exists yet AFAIK, however.
Another option would be to insert a step into the build process which optimizes the module(s) before wrapping them in a component.
Christoph Brewing (Mar 20 2025 at 13:57):makes sense, thank you very much!
Notification Bot (Mar 20 2025 at 13:57):Christoph Brewing has marked this topic as resolved.
Alex Crichton (Mar 20 2025 at 14:26):You can explore modules within a component by using wasm-tools component unbundle, but there's no reverse right now to put them back in (but if you're using a component runtime you should still be able to weave everything together)
Christoph Brewing (Mar 20 2025 at 14:28):My current setup is as follows: I am compiling Rust code + WIT to a component which I transform to a module + glue code for use in python. Perhaps, python tooling is able to use components already (?) but back in the days it could only deal with modules...
What stroke me is that AFTER having done the transformation, I use wasm-opt to optimize the module. The component, however, remains "unoptimized". That is how I started wondering.
fitzgen (he/him) (Mar 20 2025 at 14:53):also it is hypothetically possible for wasm-opt (or a similar tool) to optimize modules within the component with the assumptions about their usage inside that component and do things like cross-module inlining and DCE of exported core functions that aren't used by any component export or whatever. sort of similar to wasm-opt's meta-DCE for JS and Wasm, but for the component layer and Wasm. but this is a large-ish feature to add or new tool to write and no one has gotten around to it afaik.
Joel Dice (Mar 20 2025 at 15:14):Perhaps, python tooling is able to use components already (?) but back in the days it could only deal with modules...
If you're talking about wasmtime-py, it has limited support for running components, but it can't handle most WASIp2 imports due to lack of resource support.
Christoph Brewing (Mar 20 2025 at 15:19):Yes, that is what I meant.
Our technical context is: We use the same WASM functionality in Big-Data frameworks like Polars and PySpark as well as embedded in services (Docker with gRPC, for example). The former is Python based while the latter is Rust based.
My nucleus are WASM components. For Python, I transform them using wasmtime-py. It is the output of wasmtime-py, e.g. root.core0.wasm, which I can process further with wasm-opt, e.g. wasm-opt -O3.
The Rust based services consume the components directly.
primoly (Mar 21 2025 at 17:53):No such tool exists yet AFAIK
For the simple “optimise modules within” approach there’s https://github.com/esoterra/component-opt, but I don’t know if it still works with current components as its last commit is pretty old.
Last updated: Apr 09 2025 at 00:13 UTC