为什么for循环的100000次迭代比50000快？

Question

I've been working on this page to graph the performance of different aspects of javascript. In the process of trying to graph a simple for loop at a varying number of iterations I've found that the speed of the loop seems to dramatically increase at some point over 50000 iterations and I am very interested to know why.

Here's the loop I'm using:

var oN = function (n)
{
    var startTime;
    var endTime;
    startTime = window.performance.now();
    for (var i = 0; i <= n; i++) {};
    endTime = window.performance.now() - startTime;
    return endTime.toFixed(2);
}

The value of test is n=1000000 in this picture

Answer 1

Obviously there are a lot of factors here, but this article from Chris Wilson at Google about how Chrome's two JIT compilers work may explain part of what you are seeing.

In particular:

The Optimizing Compiler

In parallel with the full compiler, V8 re-compiles "hot" functions ( that is, functions that are run many times ) with an optimizing compiler. This compiler uses type feedback to make the compiled code faster - in fact, it uses the types taken from ICs we just talked about!

In the optimizing compiler, operations get speculatively inlined (directly placed where they are called). This speeds execution (at the cost of memory footprint), but also enables other optimizations. Monomorphic functions and constructors can be inlined entirely (that's another reason why monomorphism is a good idea in V8).

You can log what gets optimized using the standalone "d8" version of the V8 engine:

d8 --trace-opt primes.js

(this logs names of optimized functions to stdout.) Not all functions can be optimized, however - some features prevent the optimizing compiler from running on a given function (a "bail-out"). In particular, the optimizing compiler currently bails out on functions with try {} catch {} blocks!

So you can compare your original , with a version inside try {} catch {} blocks to prevent the optimizing compiler from interfering, and you will probably get a result closer to what you originally expected.

Answer 2

It's unclear from your question whether you fully understand statistics or the scientific method, so it may be that a quick recap will be useful. Apologies if you do understand, it may be a misapprehension on my part, but I think it's preferable to explain anyway, since the next person reading your question may gain valuable insight even if you don't.

---

Re statistics, unless you're basing your results on a relatively large sample size, the results cannot be relied upon, especially when the sort of timings you're examining (on the order of ¹ / _{10000 ^th} of a second) can easily be swamped by a bit of "noise".

For example, you may find that the computer you're testing it on with hit by a burst of activity by a different process when running the 50K test.

There are a number of ways to mitigate this issue, such as running with a lot more loops (so that any short-duration noise will have less of an impact), or running the test a great many times, averaging the results (for the same reason).

---

Re the scientific method, it's a good idea to perform experiments only changing one variable at a time: scientists use the phrase "all other things being equal" quite a bit and for good reason.

What I'm getting at here is the possibility that your Javascript interpreter is, at some point, recognising that the code in the loop is being run a great many times and is therefore performing a JIT conversion on it.

Chrome does do JIT compilation , containing a baseline JIT compiler which gets run on all code, and an optimising compiler which is more targeted but can produce far faster code.

To test that premise (that it's the JIT compiler), and assuming you're doing all the iteration sets in a single program run, you could reverse the order of them, or warm up the program by running a couple of 100K cycles first (throwing away the results).

Here are the results from Chrome under Windows. The code is taken from:

var oN = function (n)
{
    var startTime;
    var endTime;
    startTime = window.performance.now();
    for (var i = 0; i <= n; i++) {};
    endTime = window.performance.now() - startTime;
    return endTime.toFixed(2);
}

alert(oN(500000));
alert(oN(50000));
alert(oN(5000));
alert(oN(500));

with the order of the alert calls being the only thing changing. The figures were extracted from ten separate runs and averaged to produce the below results.

With the alert calls in ascending order, we see something similar to you:

   500  0.02
  5000  0.08
 50000  0.80 \
500000  0.61 / strange behaviour here

Putting them in descending order in the source gives a slightly different view:

   500  0.00
  5000  0.02
 50000  0.79
500000  2.21

which is seemingly much more logical.

I'd suggest running the same tests on your browser (or just reverse the order using your own test harness) to see if you have similar results.

Answer 3

I think you should try the same code more times. I executed your code but get normal result.Try to let n be a bigger number, the inaccuracy of the test will be weakened. Moreover, your vacant loop can be optimized. Please avoid making your loop nonsense. The browser is busy at the beginning of page loading, arranging doms worming up engines, etc. If you try to call this later the result maybe become normal.

http://jsfiddle.net/87nt9gtg/3/

When the same code is executed the second time, the procedure will be optimized by the browser. So this time it may be slow, but will be faster in later times.

Answer 4

Try something like this:

var oN = function (iteration, n)
{
    var startTime;
    var endTime;
    var sum = 0;
    for (var i = 0; i < iteration; i++) {
        startTime = window.performance.now();
        for (var j = 0; j < n; j++) {
            var dummy = j * i;
        }
        sum += window.performance.now() - startTime;
    }
    return (sum / iteration).toFixed(2);
}