> We've been kicking around the idea of an "unsafe but fast" compile for > exactly this reason.
I always thought the compile was "unsafe" already. Hasn't the GWT philosophy been to perform type safety/bounds/null checks only in hosted mode, if at all? Are there many such checks currently left in compiled code? I've even suggested adding more hosted mode-only checks and been rejected because of the "cost" of such runtime validations. On Tue, Nov 11, 2008 at 10:30 AM, Scott Blum <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
