The logic would have to be a little more complicated than that, since the method invocations could have side effects (checkIndex(i++, x=y, etc)) which would need hoisting.
-Ray On Thu, Nov 13, 2008 at 3:02 PM, Miroslav Pokorny <[EMAIL PROTECTED]> wrote: > This problem could be solved by introducing the ability to remove methods > marked with a particular annotation when some option was enabled and have > them eliminated accordingly. > > Imagine the ClassCastChecking and ArrayIndexChecking were done by two > methods on some imaginary helper class used by the gwt runtime. > > class GwtRuntime > @CheckClassCast > - checkClassCast > > @CheckArrayIndex > - checkArrayIndex > > Given that the compiler in this contrived example insert calls to the above > two methods all over the place one could easily remove them if you wanted to > improve performance as per Ray's suggestion. > > Pseudo code for the JModVisitor could look like this... > > Visit all method target invocations. > if target method has one of the eliminate me annotations then > remove method invocation. > end if > > If the actual list of annotations could be set on the command line it would > also allow me to eliminate my own check methods which i might not want in my > super fast production version. > > As a side note the problem with asserts is its an all of nothing its quite > difficult / hard to pinpoint that one wants to remove only one type of js > construct as opposed to all. Using different annotations allows one to > categorise and eliminate at will. > > > On Thu, Nov 13, 2008 at 9:03 PM, Ray Cromwell <[EMAIL PROTECTED]> wrote: >> >> Bruce, >> I'm kinda swamped myself right now, but I can whip something up >> after Thanksgiving. I like John's proposal too, since I like more >> powerful general purpose optimizations, but it seems like a lot more >> work than yours, and given time constraints I'd probably hack in your >> -X proposals. Of course, I'd like to hear any and all objections from >> the GWT team before I start a patch, since there's a difference >> between "potentially unsafe" and "guaranteed to break correct >> programs" :) >> >> -Ray >> >> >> On Tue, Nov 11, 2008 at 12:02 PM, Bruce Johnson <[EMAIL PROTECTED]> wrote: >> > How about we start a convention for -Xunsafe:yyy flags, like >> > >> > -Xunsafe:disableArrayIndexChecks >> > -Xunsafe:disableClassCastChecks >> > -Xunsafe:disableDefensiveCollections >> > >> > then we'd want a roll-up flag like >> > >> > -Xunsafe:all >> > >> > Of course, we'd want to not document these. >> > @Ray: The compiler guys are slammed right now. But if you have anything >> > resembling a patch that could start this pattern, I think that's the >> > only >> > realistic way to get this done in the short term. Also, I'd like to see >> > if >> > Scott/Lex/anyone else disagree before we proceeded down this path. >> > On Tue, Nov 11, 2008 at 2:47 PM, Ray Cromwell <[EMAIL PROTECTED]> >> > wrote: >> >> >> >> Is there any objection to changing the checkIndex() method in >> >> AbstractList to an assert? I suppose one might want JRE behavior in HM >> >> even if assertions are disabled, but perhaps we could just check >> >> !GWT.isScript() and use if vs assert. I noticed that if you hammer on >> >> ArrayList, a very large number of calls are generated to checkIndex. >> >> Current, about 1.5% of runtime. There's also it's friend, setCheck >> >> too. >> >> >> >> These seem like easy performance wins with very little work, of >> >> course, we want the compiler to continue to get better at well, like >> >> doing range check elimination where it can. :) >> >> >> >> -Ray >> >> >> >> On Tue, Nov 11, 2008 at 7:54 AM, Bruce Johnson <[EMAIL PROTECTED]> >> >> wrote: >> >> > On Tue, Nov 11, 2008 at 10:51 AM, Isaac Truett <[EMAIL PROTECTED]> >> >> > wrote: >> >> >> >> >> >> > I'm curious what things you're referring to here. Generally, I >> >> >> > think >> >> >> > we're >> >> >> > pretty open to more checks in hosted mode. As an example, hosted >> >> >> > mode >> >> >> > always >> >> >> > runs with assertions enabled. >> >> >> >> >> >> More assertions are exactly what I've been hoping for. The one case >> >> >> that's stuck with me was issue 2365. As I understand it, those >> >> >> assertions (and the check method, if only called in assertions) will >> >> >> all be compiled away, so there's no size or performance penalty in >> >> >> web >> >> >> mode. >> >> > >> >> > That's exactly right. And as we add new library classes, I anticipate >> >> > we'll >> >> > be doing a lot more assertion checking versus if/then/throw type >> >> > tests. >> >> > This >> >> > is one area where I honestly believe the traditional Java patterns >> >> > are >> >> > just >> >> > plain wrong: coding that's far too defensive. >> >> > > >> >> > >> >> >> >> >> > >> > >> > > >> > >> >> > > > > -- > mP > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
