Do these have to include the Python/JavaScript binaries in the final binary in order to work? Is there a lot of overhead here?
yes, they both link a whole python/js interpreter into the component. Python components are at least 40MB while jco componenrs are around 8MB I think. with custom quickjs runtime, I could get components that run js under 1MB but that's with taking every shortcut and optimization just to see how small I could get it
unless you have slow internet or low hdd space, this shouldn't be a problem. Though the files are big, loading the bytecode is still very fast
Suppose I have 100 different apps written in python that I want to run. Is there a way to share the python/js binary between them, so that it doesn't have to be loaded from my database along with the script?
For context, I'm trying to make a platform that lets users write WASM apps. It would be nice if there was a way to make it so that a few supported runtimes (python, js) don't need the user to also upload the whole runtime
That's the long-term vision for sure: with graphs of modules in components, one could ideally have one shared (e.g.) spidermonkey.wasm
or cpython.wasm
that is identical for all JS or Python programs, and somehow deduplicated
I know some folks were working on dynamic linking (@Joel Dice and others have thoughts?) but at least in JS we're not quite there yet
Thanks, that's exactly what I would need. It's fine if it's not supported yet, but if any languages/versions do support it, I can focus on supporting those first.
Is there a place where added support for this would be announced? Something I can periodically check, or a newsletter, etc.?
probably here on this Zulip, potentially on the BA blog if big enough? I know there are some other efforts to do developer-targeted comms e.g. @Bailey Hayes was running a stream for a while. I don't know of any "BA-wide changelog" that would definitely capture this though
I read that javy uses this technology to reduce binary size, but it might not be fully compatible with components, yet: https://github.com/bytecodealliance/javy?tab=readme-ov-file#creating-and-using-dynamically-linked-modules
What’s the difference between javy and jco?
different js engines and wasi vs components?
Chris Fallin said:
That's the long-term vision for sure: with graphs of modules in components, one could ideally have one shared (e.g.)
spidermonkey.wasm
orcpython.wasm
that is identical for all JS or Python programs, and somehow deduplicated
This is already technically possible with Wasmtime and "just" requires an embedding to implement, which is certainly on our collective radar.
What’s the difference between javy and jco?
As Ralph alluded to, Javy uses QuickJS while jco uses SpiderMonkey and Javy only supports WASI preview 1 while jco supports the component model. Javy is capable of producing very, very small binaries in the kilobytes range.
For reference, this is the componentize-py
issue about importing a CPython .so
file instead of bundling it.
All the basic infrastructure needed to make that work already exists; the main challenge right now is that componentize-py
currently relies heavily on build time pre-initialization to execute top-level Python code and retrieve import
ed dependencies from the filesystem (see https://github.com/bytecodealliance/componentize-py/issues/23). That pre-init step involves modifying the core modules (including the CPython .so
) to apply the pre-init snapshot. So we'd need to decide how to package that snapshot in such a way that it can be applied to a stock CPython .so
file at instantiation time rather than at build time. I don't foresee any serious issues there, but it will require some effort.
Last updated: Dec 23 2024 at 13:07 UTC