My feeling is that even the compilers written in CS101 will optimize this. I'm guessing that Google tested their code with V8, performance was fine, and they thought nothing of it.
I just did a benchmark with node.js. I made a 50000000 element array, and timed how long each way took.
Trial one:
for( var i = 0; i < array.length; i++ ) { array[i]++ }
That took, on average, 0.93001866 seconds.
Trial two:
for( var i = 0; i < len; i++ ) { array[i]++ }
That took, on average, 0.809920 seconds.
A lot of stressing-out over what ends up being a rounding error.
> My feeling is that even the compilers written in CS101 will optimize this.
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.
> My feeling is that even the compilers written in CS101 will optimize this
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.
It's not about a single 50mil element array. It's about sub-optimal code running in a bunch of places and it adds up. But in any case this probably won't be the bottleneck.
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.
Comments
My feeling is that even the compilers written in CS101 will optimize this. I'm guessing that Google tested their code with V8, performance was fine, and they thought nothing of it.
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.
A rounding error that causes a fast-paced Javascript game to crawl to a laggy stutter when repeated all over the place.
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...
That stackoverflow article points to http://www.onaluf.org/en/entry/13
which explains the issue is a lot more complicated then just a property lookup.
Or a 13/80 difference, which is in the 15%+ range. It's a rounding error on a total time of many seconds, but not in the realm of the very fast.
> My feeling is that even the compilers written in CS101 will optimize this.
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.
> My feeling is that even the compilers written in CS101 will optimize this
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.
For js running in a browser this does not matter but on a server this will make a huge difference.
How many 50 million element arrays do you have?
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.
It's not about a single 50mil element array. It's about sub-optimal code running in a bunch of places and it adds up. But in any case this probably won't be the bottleneck.
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.
Bahahhaaa, because we all use our servers to process 50 million element arrays.