2010/12/22 YANG Xudong <[email protected]>:
> Why do that when the compiler does it for you, and probably in a better way?
> It's totally reasonable for a compiler to try to optimize a normal for-loop
> written like
> for (i = 0; i < arr.length; i++) // where i is defined somewhere by a var
> statement
> because it's the most used form of for-loops. Just for example, it could
> check _very specifically_ if the second part of the statement is of the form
> "X < Y.length", and if so, cache the length of the array _internally_. It
> might even be faster than you doing the caching manually in that your way
> might introduce more overhead involving
Compilers can't optimize things to be nonequivalent. Consider this
example from Math:
a^2 = 16
a = 4
The equtations are nonequivalent because actually there will be 2 possibilities:
a = 4 and a = - 4
There are cases where the two are the same (eg.: for 0), but you can't
make that assumption generally.
Similarly `array.length` cannot be cached by the compiler because it
can change during the loop.
for (var i = 0; i < array.length; i++) {
// some condition triggers change in the array
if (i == 5) {
array.push(elem);
}
// do smth
}
If the compiler would optimize the length to be static, the loop
weren't execute for the new element.
So there are cases when caching `array.length` gives the same result
as not caching it, but again, you can't make that assumption
generally.
This optimization is the most effective when working with the DOM
because getting the `length` of a NodeList is a very expensive
calculation, and doing it for every iteration is highly inefficent.
- Balázs
eg. creating symbol table entries.
> I'm not sure about that, but I'm just trying to prove that you consciously
> doing some sort of optimization does not necessarily result in better
> performance than not doing it.
> P.S. please use arr.forEach.
> =======================
> 杨旭东 YANG Xudong "Wyverald"
> Twitter - Tumblr - GitHub - Douban
> Juntos, unidos, triunfará nuestro deseo de ser el mejor
> alias please=sudo
> please rm -rf /
>
>
> On Tue, Dec 21, 2010 at 20:54, jemptymethod <[email protected]> wrote:
>>
>> On Dec 19, 4:48 am, Szymon Piłkowski <[email protected]>
>> wrote:
>> > Hello,
>> >
>> > So, we've got new javascript engines (v8/jagermonkey), which will use
>> > JIT compilers to do their magic and optimise performance of our core.
>> > The question is: should we still use our own magic to do the same job,
>> > or should we start being nice to the compilers and leave such problems
>> > to them?
>>
>>
>> --
>> To view archived discussions from the original JSMentors Mailman list:
>> http://www.mail-archive.com/[email protected]/
>>
>> To search via a non-Google archive, visit here:
>> http://www.mail-archive.com/[email protected]/
>>
>> To unsubscribe from this group, send email to
>> [email protected]
>
> --
> To view archived discussions from the original JSMentors Mailman list:
> http://www.mail-archive.com/[email protected]/
>
> To search via a non-Google archive, visit here:
> http://www.mail-archive.com/[email protected]/
>
> To unsubscribe from this group, send email to
> [email protected]
>
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
