10

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.

enter image description here

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?

JiminP
  • 2,136
  • 19
  • 26
  • 4
    Reason? Apart from that each of the named browsers has its own implementations of JavaScript and are therefore free to optimize however they like. – Jamiec Sep 07 '11 at 10:46
  • @Jamiec But I think `a – JiminP Sep 07 '11 at 10:49
  • @Jiminip The call to `Math.min` will be compiled and the method will perhaps be inlined. Perhaps in Firefox it is inlined with super-fast code while the `if` remains an `if`. – xanatos Sep 07 '11 at 11:17
  • @JiminP: "calling a function takes more time than a single `if`" **if and only if** that function is not special-cased in the JavaScript engine and replaced with optimized machine-code. When that is done, then the function can be faster than even the corresponding `if`. – Joachim Sauer Sep 07 '11 at 11:18
  • Interesting, but when I run the tests on my machine, the results are consistent (perhaps I need to upgrade Firefox though - it's 3.6.3). The ternary test is always fastest, although in FF, Math.min is only 31% slower. The Math.min is not the same as < in that it accepts any number of arguments, and converts its arguments to be numeric. – Lee Kowalkowski Sep 07 '11 at 12:18
  • 1
    When I run the test in Firefox 9 I get the same results as in Chrome - `Math.min()` is 91% slower. What do we learn from it? Don't rely on browser's optimizations, they can change. Today the browser optimizes one approach better, tomorrow it might change already. – Wladimir Palant Sep 07 '11 at 12:49
  • My explanation would be, that ... no explanation exists :-) Check this related question also [How to interpret chromium firefox performance profiling results](https://stackoverflow.com/questions/65029918/how-to-interpret-chromium-firefox-performance-profiling-results-of-same-javasc). You can't be sure about anything in JavaScript literally. JS implementations & optimizations in browsers can differ drastically. We need ECMA standard which would cover JavaScript implementation issues in more details, for it being **cross-browser comparable**. – Agnius Vasiliauskas Nov 27 '20 at 06:56

2 Answers2

8

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).

Boris Zbarsky
  • 34,758
  • 5
  • 52
  • 55
1

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.

Melvin Joya
  • 11
  • 1