Tại sao Firefox và các trình duyệt khác hoạt động trái ngược khi tính số nào lớn hơn?

Question

Hai ngày trước, khi tôi tìm thấy jsperf.com có bộ sưu tập nhiều thử nghiệm hiệu suất javascript, tôi đã duyệt một số kiểm tra.

Một trong các thử nghiệm là this, so sánh Math.min(a,b) với a<b?a:b. Khi tôi chạy thử nghiệm này trên Google Chrome, hóa ra là a<b?a:b nhanh hơn nhiều so với Math.min(a,b) (Trên Chrome 14, đầu tiên là 53,661,381 ops/s và thứ hai là 419,830,711 ops/s). Các trình duyệt web khác có kết quả tương tự.

Tuy nhiên, trên firefox, kết quả ngược lại. Math.min(a,b) nhanh hơn nhiều so với a<b?a:b! Đầu tiên là 374,219,869 ops/s và thứ hai là 79,490,749 ops/s trên Firefox 6.

Khi tôi đăng tải này trên Facebook, ai đó nói rằng: "Kể từ khi Firefox là dự án mã nguồn mở, các nhà phát triển tối ưu Math.min, nhưng Google Chrome đã không , vì Google Chrome chỉ là một sửa đổi của Chromium ", nhưng (bên cạnh tuyên bố ở trên là không hoàn toàn đúng), điều đó không có lý do, vì điều đó không giải thích lý do tại sao Google Chrome a<b?a:b và Firefox Math.min(a,b) hoạt động ở tốc độ tương tự và Google Chrome Math.min(a,b) và Firefox a<b?a:b hoạt động ở cùng tốc độ, bởi vì nếu Firefox nhanh hơn Google Chrome, thì Googl ecủa Chrome sẽ chậm hơn nhiều so với a<b?a:b của Firefox.

Tóm tắt:

1. Trên các trình duyệt khác, a<b?a:b nhanh hơn Math.min(a,b). Tuy nhiên, trên Firefox, Math.min(a,b) nhanh hơn a<b?a:b.
2. Kể từ tốc độ Math.min(a,b) trên Firefox ≒ tốc độ a<b?a:b trên Google Chrome và tốc độ a<b?a:b trên Firefox ≒ tốc độ Math.min(a,b) trên Google Chrome, "Firefox chậm" hoặc "Firefox nhanh" không thể là lý do .

Có bất kỳ lý do nào khiến cho điều này xảy ra như thế nào?

Answer 1

Có một vài điều đang diễn ra tại đây.

Trước hết, trong Firefox 6 có hai trình biên dịch JIT khác nhau: TraceMonkey và JaegerMonkey. Mà một trong những được sử dụng cho một bit nhất định của mã phụ thuộc vào một số heuristics; các heuristics này có xu hướng ưu tiên TraceMonkey cho mã với các cuộc gọi hàm. Điều đó xảy ra với mã TraceMonkey đơn giản là hầu như luôn luôn nhanh hơn JaegerMonkey; đó là trường hợp cho cả hai đoạn mã được trình bày ở đây, đặc biệt.

Trong tiêu chuẩn cụ thể này, mã hóa Math.min được biên dịch bằng Tracemonkey, vì đó là cuộc gọi hàm. Các codepath điều hành trinary được biên dịch với JaegerMonkey.

Bạn có thể thử nghiệm bằng cách truy cập about:config, đặt jit trong trường bộ lọc và tắt một hoặc cả TraceMonkey (tracejit trong danh sách) và JaegerMonkey (phương thứcjit).Nếu bạn làm điều đó, bạn sẽ thấy rằng trên điểm chuẩn cụ thể này, toán tử trinary nhanh hơn Math.min cho mỗi trình biên dịch riêng lẻ, do đó, đảo ngược bạn thấy so với các trình duyệt khác chỉ là một hàm của việc sử dụng các trình biên dịch khác nhau.

Bây giờ, tại sao Math.min thường chậm hơn toán tử ba chiều ... trước hết nó phải làm nhiều việc hơn; các câu trả lời nó trả về KHÔNG giống như toán tử trinary, nếu bạn kiểm tra cẩn thận. Thứ hai, nó thường được thực hiện như một cuộc gọi hàm, đó là nơi mà hầu hết các chi phí đến từ (mặc dù TraceMonkey thực sự làm inline nó một cách rõ ràng trong mã được tạo ra, đó là lý do tại sao hiệu suất của hai đoạn không khác với TraceMonkey).

Answer 2

Tôi đã có câu hỏi tương tự sau khi đọc, Efficient Javascript trên Dev.Opera và chạy một số điểm chuẩn khác nhau. Tôi nghĩ rằng phần đó là một chút sai lầm. Có rất nhiều điều làm chậm Math.min nhưng không có gì thực sự giải thích hiệu suất trên Google Chrome so với Firefox hoặc IE9.

Những điều tôi nghĩ chậm Math.min

• tận dụng những lập luận phản đối
• có để kiểm tra nếu có giá trị là NaN
• những thứ khác như trở về Infinity nếu không args được đưa ra và + 0> -0

Để biết thêm thông tin chi tiết, hãy xem http://qfox.nl/ecma/366 để triển khai mẫu.

P.S. Tôi biết câu hỏi này là cũ, nhưng tôi nghĩ rằng nó có thể tiết kiệm cho tôi một chút thời gian nếu tôi đi du lịch đến quá khứ.