Component Size & Performance: JCO/SpiderMonkey vs QuickJS
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- javascript, rust, wasm
- Lĩnh vực
- compilers, performance
Hướng nghiên cứu
Tái hiện ba kích thước component đã được báo cáo, thời gian chạy fib(40) và thời gian tạo mã khi khởi động cho JCO, JCO với weval/aot và Rust với QuickJS. Issue không nêu tệp, test hoặc entry point nào, vì vậy hãy bắt đầu bằng cách yêu cầu hoặc tìm các ví dụ mã đã được hứa cung cấp và kiểm tra xem SpiderMonkey có phải là nguyên nhân hay không. Được xem là hoàn tất khi giải thích được sự chênh lệch hoặc xác định được một cơ hội tối ưu hóa cụ thể.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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:
- JCO => 13M
- JCO + weval/aot => 29M
- Rust + QuickJS => 1.9M
Running a naive fibonacci implementation just to get a sense of performance, I get for fib(40):
- JCO => 45s
- JCO + weval/aot => 29s
- 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.
- Ngôn ngữ chính
- Rust
- Star
- 392
- Fork
- 54
- Merge trung bình
- 2 ngày 18 giờ
- Pull request đã merge (30 ngày)
- 3
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của bytecodealliance/ComponentizeJS
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
enhancement
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 56/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 52/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
bytecodealliance/ComponentizeJS#335 · 3 bình luận ·
Tất cả issue của bytecodealliance/ComponentizeJS
Issue tương tự
-
bug github_actions
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
registrystack/registry-stack#1393 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
longbridge/gpui-kit#3223 ·
-
bug engine
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
rocky-data/rocky#2181 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
oasisprotocol/oasis-sdk#2523 ·
-
[indexer] [QA] Add a focused test for the new NonRetryableError / assertSocketAlive() behavior. Đang mởbot:ai-assisted component:indexer QA-roadmap status:untriaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
midnightntwrk/midnight-indexer#1557 ·