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
th...@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
-~----------~----~----~----~------~----~------~--~---
