Regardless, the Closure Compiler (that the Closure Library is made to be used for) fixes this common case.
Another example where it's more than a rounding error: http://stackoverflow.com/questions/2573212/why-is-setting-ht...
which explains the issue is a lot more complicated then just a property lookup.
Then it might be harder than you think. You can't know that array.length won't change during the course of the loop. Even in your simple example, I would say it takes a fair bit of analysis (not for a human, of course), to be certain that "array[i]++" won't add elements to the list.
Closure comes with a compiler/optimizer/minifier that will do all sorts of optimizations to your code. I am not sure if this is one of them, but I would not be surprised if the library code is optimized for readability and they let the compiler do its tricks to optimize it for speed.
My guess is that this makes no difference in real life. Should you write clean code that performs well? Yes. But should you be fixated on a tiny bug in Google's library? Nope. Send patch, get .0000000001 seconds per element back, and move on.
Still I am a fan of running the most optimal code possible on the server. Absolutely no reason not to.
Client-side js is different. Often times algorithmic optimizations have no impact (unless we are talking about animation.)
I would not trust people who do not respect optimizations like these to run code on my server.
I just did a benchmark with node.js. I made a 50000000 element array, and timed how long each way took.
Trial one:
That took, on average, 0.93001866 seconds.Trial two:
That took, on average, 0.809920 seconds.A lot of stressing-out over what ends up being a rounding error.