Fair point. Just to make my opinion clearer: all these conclusions are based on the assumption that compilers have become sufficiently smart, to the point where humans should care more about code readability/reusability/maintainability/etc. instead of optimization. In that specific case, a smart enough compiler could detect the array length change inside the loop and take relevant measures. Of course it might not be practical right now, but IMO that's the way to go in the future. ======================= 杨旭东 YANG Xudong "Wyverald" Twitter <http://twitter.com/Wyverald> - Tumblr <http://wyverald.tumblr.com/>- GitHub <https://github.com/Wyverald> - Douban<http://www.douban.com/people/45985185/> Juntos, unidos, triunfará nuestro deseo de ser el mejor alias please=sudo please rm -rf /
On Wed, Dec 22, 2010 at 18:09, Balázs Galambosi <[email protected]>wrote: > 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]<jsmentors%[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]<jsmentors%[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]<jsmentors%[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]
