tag:blogger.com,1999:blog-2515037436118935802.post3441653197274038958..comments2023-11-05T02:14:17.184-08:00Comments on Timefire: Design Patterns vs GWT Compiler: Round 1, Fight!Timepediahttp://www.blogger.com/profile/01408958797259838599noreply@blogger.comBlogger1125tag:blogger.com,1999:blog-2515037436118935802.post-78831759924952861652008-06-06T20:20:00.000-07:002008-06-06T20:20:00.000-07:00Nice writeup, Ray! We want to make it ever more tr...Nice writeup, Ray! We want to make it ever more true that GWT rewards sound software construction with better performance. <BR/><BR/>I'm happy with where we are, to be sure, but it's also exciting to think that we're only scratching the surface with the current compiler optimizations. For example, I really hate seeing the "s$iterator.items.length" in the loop test (vs. caching it in a local var). I think we can probably generate a temporary to cache it in many cases where it can be proved safe.<BR/><BR/>More in the realm of vaporware -- but too exciting not to mention -- are a set of optimizations we've been kicking around to address the example you used of having multiple class implementing Iterable. It seems like function cloning combined with the type tightening we already do could allow us to inline the same function differently for different call sites. It's quite like C++ templates at that point, though it would just happen magically. <BR/><BR/>We also have a related idea about doing <BR/>"per-instance" optimizations, tentatively called "type sharding". This would let you optimize with the knowledge of invariants for one given class of instances of a class. It would reward you for having mostly immutable object state after construction because it could optimize methods for one particular instance with the knowledge of the immutable state. Hard to explain, but promises to be really cool. We can talk about it more on the GWT Contributors list if you're interested.Bruce Johnsonhttps://www.blogger.com/profile/12699642840488867708noreply@blogger.com