Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Component Size & Performance: JCO/SpiderMonkey vs QuickJS

Aperta
#291 9 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
javascript, rust, wasm
Ambito
compilers, performance

Direzione di ricerca

Riproduci le tre dimensioni dei componenti riportate, i tempi di fib(40) e i tempi di generazione del codice all’avvio per JCO, JCO con weval/aot e Rust con QuickJS. La issue non indica file, test o punti di ingresso, quindi inizia richiedendo o individuando gli esempi di codice promessi e verificando se la responsabilità è di SpiderMonkey. Il lavoro è completato quando viene spiegata la discrepanza oppure viene identificata una concreta opportunità di ottimizzazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

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.

Lingua principale
Rust
Stelle
392
Fork
54
Merge medio
2g 18h
PR unite (30g)
3

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di bytecodealliance/ComponentizeJS

Tutte le issue di bytecodealliance/ComponentizeJS

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.