~+700% regression in wasm-opt --nm performance from Emscripten 3.1.38 -> 4.0.19
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- wasm
- Lĩnh vực
- compilers, performance
Hướng nghiên cứu
Bắt đầu với điểm vào wasm-opt --nm và so sánh trình phân tích cú pháp văn bản mới được giới thiệu trong commit #6371 với trình phân tích cú pháp trước đó. Tái hiện hồi quy trên tệp .wast được báo cáo và sử dụng các profile được liên kết để xác định đường dẫn chậm. Được coi là hoàn tất khi hiệu năng được khôi phục về gần ~11 giây trước đây, đồng thời vẫn giữ nguyên hành vi của trình phân tích cú pháp mới.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Previously we were using Emscripten 3.1.38.
In some of our code stripping related unit tests, we are running wasm-opt --nm on a .wast file. In old Emscripten 3.1.38, this step took ~11 seconds.
After updating to Emscripten 4.0.19, the same wasm-opt --nm step is now taking about 87 seconds, about ~8x increase from before.
Bisecting the issue, the performance regression has arrived in #6371:
commit 956d2d89d530012885c1f88c87bf8b872c187b70 (HEAD)
Author: Thomas Lively tlively@google.com
Date: Thu Apr 25 14:55:12 2024 -0700
[Parser] Enable the new text parser by default (#6371)
The new text parser is faster and more standards compliant than the old text
parser. Enable it by default in wasm-opt and update the tests to reflect the
slightly different results it produces. Besides following the spec, the new
parser differs from the old parser in that it:
- Does not synthesize `loop` and `try` labels unnecessarily
- Synthesizes different block names in some cases
- Parses exports in a different order
- Parses `nop`s instead of empty blocks for empty control flow arms
- Does not support parsing Poppy IR
- Produces different error messages
- Cannot parse `pop` except as the first instruction inside a `catch`
CC @tlively
A samply profile of the slow behavior can be observed https://share.firefox.dev/4aUcR0c
If I back out to the previous commit and profile that, then I get the following looking profile:
https://share.firefox.dev/4sc8owW
I wonder if there might exist any optimizations that could bring the performance of the new parser up to par with the old one?
- Ngôn ngữ chính
- WebAssembly
- Star
- 8.6k
- Fork
- 885
- Merge trung bình
- 2 ngày 1 giờ
- Pull request đã merge (30 ngày)
- 70
Hướng dẫn đóng góp
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 WebAssembly/binaryen
-
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 76/100
WebAssembly/binaryen#9018 · 3 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
WebAssembly/binaryen#9123 ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
WebAssembly/binaryen#9122 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
WebAssembly/binaryen#9086 · 2 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
WebAssembly/binaryen#9038 · 5 bình luận ·
Tất cả issue của WebAssembly/binaryen
Issue tương tự
-
compiler/runtime
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
objectionary/eo#8869 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
EricSpencer00/Resilient#4824 · 1 bình luận ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
objectionary/jeo-maven-plugin#1758 ·
-
generics
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100