Why Firefox and other browsers perform oppositely when calculating which number is bigger?

Question

Two days ago, when I found jsperf.com which has a collection of many javascript performance tests, I browsed several tests.

One of tests was this, which compares Math.min(a,b) vs a<b?a:b. When I ran this test on Google Chrome, it turned out that a<b?a:b is much faster than Math.min(a,b) (On Chrome 14, first one is 53,661,381 ops/s and second one is 419,830,711 ops/s). Other web browsers have similar results.

However, on firefox, the result is opposite. Math.min(a,b) is much faster than a<b?a:b! First one is 374,219,869 ops/s and second one is 79,490,749 ops/s on Firefox 6.

When I posted this on Facebook, someone said that "Since Firefox is open source project, developers optimized Math.min, but Google Chrome didn't, since Google Chrome is just a modification of Chromium", but (beside that above statement is not quite right) that makes no sense, because that doesn't explain the reason why Google Chrome's a<b?a:b and Firefox's Math.min(a,b) performs in similar speed, and Google Chrome's Math.min(a,b) and Firefox's a<b?a:b performs in same speed, because if Firefox is faster than Google Chrome, then Google Chrome's Math.min(a,b) should be much slower than Firefox's a<b?a:b.

Summary :

1. On the other browsers, a<b?a:b is faster than Math.min(a,b).
2. However, on Firefox, Math.min(a,b) is faster than a<b?a:b.
3. Since the speed of Math.min(a,b) on Firefox ≒ the speed of a<b?a:b on Google Chrome and speed of a<b?a:b on Firefox ≒ the speed of Math.min(a,b) on Google Chrome, "Firefox is slow" or "Firefox is fast" can't be a reason.

Is there any reason why (how) this happens?

Answer 1

There are a few things going on here.

First of all, in Firefox 6 there are two different JIT compilers: TraceMonkey and JaegerMonkey. Which one gets used for a given bit of code depends on some heuristics; these heuristics tend to favor TraceMonkey for code with function calls. It so happens that for simple enough code TraceMonkey is almost always faster than JaegerMonkey, though; that's the case for both snippets of code presented here, in particular.

In this particular benchmark, the Math.min codepath gets compiled with Tracemonkey, because it's a function call. The trinary operator codepath gets compiled with JaegerMonkey.

You can experiment with this by going to about:config, putting jit in the filter field and disabling one or both of TraceMonkey (tracejit in the list) and JaegerMonkey (methodjit). If you do that, you will see that on this particular benchmark the trinary operator is faster than Math.min for each of the compilers individually, so the inversion you're seeing compared to other browsers is just a function of the use of different compilers.

Now as to why Math.min is typically slower than the trinary operator... first of all it has to do more work; the answers it returns are NOT the same as the trinary operator, if you test carefully. Second, it's usually implemented as a function call, which is where most of the overhead comes from (though TraceMonkey actually does inline it explicitly in the generated code, which is why the performance of the two snippets is not that dissimilar in TraceMonkey).

Answer 2

I had this same question after I read, Efficient Javascript on Dev.Opera, and running some different benchmarks. I think that section is a little misleading. There are many things that slow down Math.min but none of it really explains the performance on Google Chrome versus Firefox or IE9.

Things I think slow down Math.min

• makes use of the arguments object
• has to check if any value is NaN
• other things like returning Infinity if no args are given and +0 > -0

For more in depth information take a look at http://qfox.nl/ecma/366 for a sample implementation.

P.S. I know this question is old, but I think it could save me a bit of time if I ever travel to the past.