Skip to content

Conversation

@dicej
Copy link
Collaborator

@dicej dicej commented Oct 23, 2025

This removes the built-in Wasm code generator in favor of wit-dylib, which is designed to be reused by interpreters for various languages. It avoids redundant effort and leaves us with less code to maintain overall.

This isn't particularly optimized, yet. Given how wit-dylib[-ffi] works, we have to acquire and release the CPython GIL a lot more frequently (e.g. for every parameter and result of every import and export call). I haven't measured the overhead in practice, so I don't know if it's significant; if it is, we can make changes to wit-dylib to reduce the overhead. Also, wit-dylib currently embeds a data section with a lot of metadata that we don't use, so we could slim that down if needed.

Otherwise, this should not affect the developer experience in any noticeable way.

This removes the built-in Wasm code generator in favor of `wit-dylib`, which is
designed to be reused by interpreters for various languages.  It avoids
redundant effort and leaves us with less code to maintain overall.

This isn't particularly optimized, yet.  Given how `wit-dylib[-ffi]` works, we
have to acquire and release the CPython GIL a lot more frequently (e.g. for
every parameter and result of every import and export call).  I haven't measured
the overhead in practice, so I don't know if it's significant; if it is, we can
make changes to `wit-dylib` to reduce the overhead.  Also, `wit-dylib` currently
embeds a data section with a lot of metadata that we don't use, so we could slim
that down if needed.

Otherwise, this should not affect the developer experience in any noticeable
way.

Signed-off-by: Joel Dice <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant