If the rates vary throughout a single test, it may indicate that the performance degenerates in the execution of long loops. Support for semi-precise timings (in milliseconds) is needed for these tests.
In order to estimate the actual time to perform a single operation (++ or --), we can subtract those times from the times where the studied function performs several decrements and increments. We will perform 50 decrements and 51 increments in each loop. Subtracting the times from the single-increment do test should produce exactly the times for the various amounts of 50 decrement and 50 increment operations.
In the three browsers tested, two favored do (Chimera and Safari), while the other (Explorer) favored for. Overall, Chimera was fastest, with Safari behind on an order of magnitude. We will use do for this test.
Subtract the time of the best speed for the do loop test from above from the time for the same number of iterations of this test. Recalculate the rate and multiply by 100 in order to estimate the number of increment or decrement operations per second.
Or, more simply, subtract the fastest fractional rate (cycle time) of the test above from the fastest of this.
Safari performed approximately 2,242 iterations of the 101-fold loop per second, or ~256,416 single operations/sec. [The max speed of do alone was 99,900 i/s, so 1s / (1/2242 - 1/99900)s/i * 100operations/i = ~256,416.] The score for Chimera was 5,263,157 [1 / (1/50000 - 1/1000000) * 100], and for Explorer, 2564760 [1 / (1/25000 - 1/990099) * 100]. For reference, Mozilla is 5,605,381, OmniWeb is 5,154,639, and Opera doesn't support precise timings.
From this information we can judge the loop's own effect on performance. Since we know that Chimera's execution speed on the reference computer is 5,263,157 add-or-subtracts per second, we can infer that if it takes 10000/5263157 = 1.9 ms to do the additions in a 10,000-iteration loop, then it takes this much less to actually run the loop.
The test in this case took 8.4 ms, so the time consumed on maintaining the loop itself was 8.4 - 1.9 = 6.5 ms per 10,000 iterations, for a theoretical maximum speed of 1,538,461 iterations per second.
We can see that it takes more effort (about two and a half times as much) to loop than to do any single operation within the loop. Some of this may be in evaluating the conditional; some of it may be in other details.
By running a test of conditional evaluators, we can see that there must be other details adding to the cost of each loop iteration.
Because some browsers do not perform all comparisons, they will not return accurate results for this test.
You can test the lossage from using functions to organize code by measuring the latency of their invocation and return time. (Note: some browsers prefer functions defined internally (within the timed function), as in this test; these will otherwise perform worse, taking a longer time to follow the JavaScript daisy chain to reach the globally-defined function; this can effect performance by a factor of five, in particular Mozilla/Netscape implementations--which are generally the fastest but also the most sensitive to this effect; other browsers seem to have little change in performance either way.)
Reference: Safari = 56,000/s, IE = 113,765, Chimera = 616,396.
| Loop Tests | Camino | Opera 6.02 | Mozilla 1.3 | Internet Explorer 5.2.2 | Safari | Mozilla Firebird 0.6 (Mac) | Internet Explorer 6 (Windows) |
|---|---|---|---|---|---|---|---|
| functions (calls/sec) | 622924 | 32461 | 75240 | 115529 | 49423 | 605083 | 192419 |
| operations (executions/sec) | 4870130 | 340136 | 5208333 | 2043318 | 217391 | 5376344 | 9885982 |
Arbitrary speed tests can be performed with the configurations and shortcuts already determined. Reserved words in the test are i, n, g.
It would be better not to prompt for questions which may not be understood. To speed up the large tests the argument to the repeater function could be changed to 3 or 5 to reduce time at the sake of accuracy. This would require some tampering with the timing logic. [Done.]
Now it would be better to evaluate the performance at the first, so faster browsers could fulfill more complete tests, without hard-fixing the slower ones to a minute or more of waiting. [Done. Basically it allows the do loop to run for up to 10 ms, and then configures the iteration number with this value. If your computer/browser can get constantP to 6 or 7 (10^6 = 1,000,000), then you've got good stuff.]