bytecodealliance / bytecodealliance/ComponentizeJS
Component Size & Performance: JCO/SpiderMonkey vs QuickJS
- Lingua principale
- Rust
- Stelle
- 391
- Fork
- 53
- Merge medio
- 3g 5h
- PR unite (30g)
- 1
Descrizione
Hi there,
Let me start by saying that I'm missing a lot of context and that my approach is extremely naive, so please tell me to bugger off. Yet, I would still like to better understand the rational or state-of-the-world.
I'm playing around with various WASI components, mostly in Rust and JS. I did certainly notice the chunky component size of my JS components whenever wasmtime had to recompile them. I didn't think too much of it, thinking that's just the price to pay for bundling an interpreter. However, eventually I built a rust WASI component bundling QuickJS (via the rquickjs crate), which turned out to be slightly faster and significantly smaller. For comparison:
1. JCO => 13M
2. JCO + weval/aot => 29M
3. Rust + QuickJS => 1.9M
Running a naive fibonacci implementation just to get a sense of performance, I get for `fib(40)`:
1. JCO => 45s
2. JCO + weval/aot => 29s
3. Rust + QuickJS => 26s
And startup codgegen/compile times are hugely different roughly propotional to the difference in component size.
I've no clue if this actually SpiderMonkey or if there's something else going on, however I didn't expect the difference to be quite so substantial. Could you help me understand what I'm missing or is this an opportunity?
Thanks,
Sebastian
EDIT: I'm happy to back this up with code-examples, I mostly just wanted to reach out and see if this is something you're aware off or have seen before.
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Valutazione
Questa issue non è ancora stata valutata.