Does anybody actually have a patch that does any of this? I'd love to see
numbers on flags like:

-Xopt:skipGenericCasts
-Xopt:skipArrayElemTypechecks
-Xopt:eagerClinits
-Xopt:obfuscatedClassLiterals

I think there's a bunch of pretty low-hanging fruit here.

On Fri, Jan 23, 2009 at 5:10 PM, Andrés Testi <andres.a.te...@gmail.com>wrote:

>
> Ray:
>
> What happends if you extends ArrayList to avoid generics?:
>
> class RangeAxisArrayList extends ArrayList<RangeAxis>{}
>
> - Andrés
>
> On 23 ene, 16:52, Ray Cromwell <cromwell...@gmail.com> wrote:
> > Here's the scoop. I changed a field in Chronoscope from RangeAxis[] to
> > List<RangeAxis> and suffered ~50% performance regression. An Axis is a
> class
> > responsible for mapping values in the range [low, high] to [0,1], among
> > other things, so it is a hot class/method in Chronoscope. After
> profiling, I
> > noticed the method was no longer being inlined, and a huge number of
> calls
> > to dynamicCast/canCastUnsafe appeared. This brings to mind two
> > optimizations:
> >
> > 1) if a method's return type is covariant in a generic type, do not
> insert a
> > cast or cast check. Assume that the method *will* return objects of this
> > type at the callsite.
> > 2) eliminate dynamicCast/canCastUnsafe altogether. These methods only
> exist
> > to throw class cast exceptions. I can't believe that there's any code
> that
> > actually expects these exceptions and depends on them being thrown except
> > perhaps unit tests. Anyone running unit tests or UI tests in hosted mode
> > will get these exceptions during development, so it seems the only use
> case
> > might be web-mode unit tests.
> >
> > But for production deployed code, dynamicCast/canCaseUnsafe/setCheck/et
> al
> > seem to just be bloat and a performance hit to boot. Can we get a compile
> > mode that removes them? Maybe an -XX method, or some other mechanism
> which
> > says "I want potentially unsafe, but super fast code"?
> >
> > -Ray
> >
>

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

Reply via email to