Apropos, http://timepedia.blogspot.com/2008/06/design-patterns-vs-gwt-compiler.html
The compiler can do a pretty good job already, and perhaps with some form of escape analysis it can elide the object generation. In the example given, the lifetime of the iterator is the scope of the loop, and as long as it doesn't escape the loop (in most cases it doesn't), we can 'inline' the iterator fields as temporaries in the loop. -Ray On Fri, Jun 5, 2009 at 10:22 PM, John Tamplin<[email protected]> wrote: > On Fri, Jun 5, 2009 at 10:15 AM, TazmanianD <[email protected]> wrote: >> >> There is an additional benefit to this optimization that goes beyond >> speeding up the compiler. It should produce faster Javascript as >> well. Unless I'm mistaken, using an iterator to iterate over a list >> requires the creation of a Javascript object to represent the >> iterator. That object creation can be avoided by iterating over the >> list by index instead. On Blueprint, we have been avoiding using the >> nice for...each construct for this very reason. Unfortunately, I >> don't have any data that suggests just how much of a difference the >> index instead of iterator makes. > > Seems like our compiler should be able to do a better job because it has > full knowledge of the possible types at the point it is generating code. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
