@mark
Your trick as mentioned (using jsni to avoid casting ) was/is used by
the generated rpc serializers to avoid / skip casts ...
Mp
On 01/04/2009, at 5:44 AM, Mark Renouf <mark.ren...@gmail.com> wrote:
>
> Got bit by this the other day. This is my current workaround for
> Comparable, since without it, a dynamicCast is called for each test
> (like in a map, using natural odering where a K must be cast to a
> Comparable<K>). I use it in tight loops where the dynamicCast overhead
> would kill performance (+20% overhead). I hope there is better support
> or an official override mechanism on it's way.
>
> package com.google.gwt.util.client;
>
> /**
> * Wraps an object and exposes a compareTo method which is executed
> without
> * runtime type safety checking. This avoids a huge performance hit
> in
> * certain cases. There is zero type safety, and this runs
> significantly slower
> * in hosted mode. Use with caution!
> */
> public class NativeComparable<K> implements Comparable<K> {
> @SuppressWarnings("unused")
> private Object a;
>
> public NativeComparable(Object obj) {
> this.a = obj;
> }
> public native int compareTo(K b) /*-{
> return
> this.
> @com.
> google.
> gwt.util.client.NativeComparable::a...@java.lang.comparable::compareTo
> (Ljava/lang/Object;)(b);
> }-*/;
> }
>
> On Feb 2, 1:14 pm, Lex Spoon <sp...@google.com> wrote:
>> On Fri, Jan 30, 2009 at 5:35 PM, Ray Cromwell
>> <cromwell...@gmail.com> wrote:
>>
>>> On Fri, Jan 30, 2009 at 2:07 PM, Lex Spoon <sp...@google.com> wrote:
>>
>>>> 1. Modify CastNormalizer to simply removes all casts, and see
>>>> what the
>>>> size difference is. This behavior would ultimately be settable
>>>> by a
>>>> flag, assuming it actually gets a significant size improvement.
>>
>>> This would be my preference actually, and not just for size, but for
>>> performance. When I profile in Firefox, I see that
>>> dynamicCast/canCastUnsafe have a huge number of invocations
>>> (easily in
>>> the top 10 hotspots), as well as chewing up about 5-10% of total
>>> CPU.
>>> Granted, my application is more intensive than most, but would
>>> definitely be a welcome improvement. I can't see many apps
>>> deployed in
>>> web-mode actually caring about accurate class cast exceptions, and
>>> hopefully, most CCEs would be caught much easier in the development
>>> process, in hosted mode, or during unit tests.
>>
>> That's higher than I realized. Certainly high enough to make a
>> strong
>> argument for being a touch less safe to gain the speed.
>>
>> Note, though, that we still don't know how many of those could be
>> removed if we had a "known to succeed" flag in JCast. It might be
>> that most of them are due to generics rather than to explicit casts
>> the user put in. In that case, the overhead might mostly go away
>> while giving up much less safety.
>>
>> Lex
>
> >
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
