Component Size & Performance: JCO/SpiderMonkey vs QuickJS

复现 JCO、带有 weval/aot 的 JCO 以及使用 QuickJS 的 Rust 的三个已报告组件大小、fib(40) 计时和启动时代码生成时间。issue 未列出任何文件、测试或入口点，因此首先请求或查找承诺提供的代码示例，并检查是否由 SpiderMonkey 导致。完成标准是解释这种差异，或确定一个具体的优化机会。

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.