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.
> >
>

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to