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.