We've been kicking around the idea of an "unsafe but fast" compile for exactly this reason. OTOH, there are a couple of things we could do to make the type checks faster even in the short term:
1) Do actual null tracking so as to omit the null check part in many cases. 2) Get away from using typeIdArray in favor of having cast information accessible directly off the object, which should be faster. 3) Make sure it's inlined in all cases. On Tue, Nov 11, 2008 at 2:14 AM, Ray Cromwell <[EMAIL PROTECTED]> wrote: > > Heads up guys, > > I just profiled my app trying to squeeze every last drop of > performance out for speedups on the iPhone which has slow Javascript, > and I noticed that the canCastUnsafe/dynamicCast functions are > collectively eating up 8.5% of the total runtime. It seems that the > sole purpose of dynamicCast() is to throw a ClassCastException where > the JVM would, but in production web-deployment mode, I would honestly > prefer the option of having these checks omitted. Yes, there are some > cases where throwing the exception would give the end user a better > error message, but if the user is able to reproduce incorrect > behavior, I think I would prefer to direct them to a debug > build/permutation which has the checks. It seems the major place where > this could trip up legitimate code is if someone was triggering CCEs > on purpose and expecting to catch them with an exception handler. > > The main reason these checks are being inserted is because I switched > from using a custom collection, to a List<Foo>, and the compiler > appears to be unable to use the generic type information of the JField > to determine that the cast is unneccessary. > > Anyway, the question for discussion is, should the compiler have an > -O2 mode which eliminates range checks, runtime cast checks, etc > > -Ray > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
