It's quit easy to determine if an argument to a checl method has side effects - if I recall there's a has side effects() ... At worst the method invocation is removed but the "block" is kept because of the sideeffects... In the end some statements have been eliminated which can only help make things just a bit faster...
Sent from my iPhone On 14/11/2008, at 11:48 AM, "Ray Cromwell" <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
