I have another idea I'd like to run past you. I've noticed that alot of
times, method inlining is hampered by the way methods are "staticified".
Let's say you have a method:
public class Foo {
int x;
public int add(int y) {
return y + x;
}
}
this will end up as Javascript
function $add(this$static, y) {
return y + this$static.x;
}
which will cause the JS Inliner to avoid inlining due to the parameters
being evaluated in a different order in the body of the function. That's
because the this$static reference is always passed as the first argument.
However, if the staticifier was changed to inspect the body of the the
function, and insert the this$static reference in the parameter list,
according to the order in which references to it were encountered, it might
allow the JS Inliner to work better, in the absense of fixing JS Inliner to
deal with out-of-order evaluation.
-Ray
On Fri, Jan 23, 2009 at 12:54 PM, Scott Blum <sco...@google.com> wrote:
> I think it's a worthwhile idea, we've talked before about some "make my
> code fast but unsafe" options.
>
>
> On Fri, Jan 23, 2009 at 2:52 PM, 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
-~----------~----~----~----~------~----~------~--~---
