bytecodealliance / bytecodealliance/ComponentizeJS

Component Size & Performance: JCO/SpiderMonkey vs QuickJS

未关闭
#291 9 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
Rust
星标
391
派生
53
平均合并
3 天 5 小时
30 天内合并 PR
1

描述

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.

贡献指南

这个仓库没有索引到贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。