javascript - Performance gain from double counter in a js "for" loop? -

while researching array assignment performance, stumbled across jsperf purportedly shows dramatic speed increase for loops of form:

var i, j = 0; (i = 0; < n; i++) {   myarray[j++] = i; } 

... in current browsers. "double increment" form totally alien me, , seems bizarre. can't find discussion on it.

many people have warned on years misleading data microbenchmarks due increasing cleverness of compiler optimizations. 1 of cases? why or why not? if jsperf written incorrectly, love see correct, revised jsperf more accurately reflects real world conditions.

there should no way double counter loop vs. single counter loop faster unless js doing extremely poor/bizarre optimization. machine level standpoint, such code use 2 general-purpose registers instead of one, having increment both. difference should small , insignificant, single counter should have slight performance edge.

the way tell sure see resulting machine instructions/disassembly.

it's possible using length isn't simple accessing variable. it's of surprise me if such case, may translate more instructions (ex: involving branching in worst case scenarios). in case, should still faster results using i instead of j , still single-counter loop.

one thing worth trying change order of tests around. possible there's going on memory previous tests related paging/caching allowing latter, double-counter test go faster. example, double counter test followed single counter test. try swapping 2 around in order they're executed , see if affects results.

update

as shown in mark's test in comments, push-numbers-redux, faster results single counter loop when avoiding length. apparently length require more instructions simple variable, perhaps branching associative array cases optimizer can't eliminate. single counter loop still beat double counter one, if we're testing regular variables against variables.

microbenchmarks

since subject raised why micro-benchmarks can bad, they're not bad there caveats associated them. test pretty micro since it's not doing meaningful user point of view. creates array of data nothing it.

about why can bad if you're trying generalize performance ideas such tests, start, hardware dynamic machine. tries predict doing, branches of code more commonly executed, transferring dram cache, etc. operating system dynamic, paging memory on fly. given dynamic nature of environment, can in danger of writing micro-test appears faster getting lucky these dynamic factors. real world tests more work, , perhaps more importantly, variety of work, tend mitigate "dynamic luck" factor can mislead believing faster when might faster specific test. don't have write full-blown large-scale applications real-world like. example, computing mandelbrot set rather simple code (can fit in 1 page) still doing enough escape micro-level dangers.

another danger optimizing compiler. can bitten in micro-benchmarks when optimizer detects causing no global side effects @ (ex: computing data discard without printing or doing cause changes elsewhere). sophisticated optimizers, can detect when computations can skipped since cause no side effects, , might find did caused things run 10,000 times faster, not because actual work being done faster, because optimizer figured doesn't need done @ , skipped outright. if, in test, place in shoes of user , can rationalize why parts of code can skipped , still give user same output/result without waiting long, optimizer can , skip code. whenever you're doing micro-benchmarks against strong optimizer , find result seems true, true , optimizer skipping work outright since noticed in superficial test doesn't need it.

last not least, focusing on micro-efficiencies pull assembly-like thinking. there's no wiggle room optimize in smarter ways when you're repeatedly testing few instructions in tight loop. want more wiggle room when staring @ performance measurements, work way coarse optimizations (algorithmic, multithreading, etc) down smallest micro-optimizations. when tests micro, end getting granular type of metal-scraping thinking right away, , can lead unhealthy obsession on saving few clock cycles when real world might present opportunity save billions instead same effort/time invested.