MethodHandle lookup&invocation performance

[Rémi Forax]

You should avoid to create constants more than once.
Also, bindTo() will create a method handle for-each call.

You can transform your code like that:

     private static final MethodHandles.Lookup lookup = MethodHandles.lookup();
     private static final MethodType mt = MethodType.methodType(String.class, String.class);

     private static MethodHandle methodhandleLookup(Object receiver, String methodName) throws Throwable {
         return lookup.findVirtual(receiver.getClass(), methodName, mt);
     }

     private static String methodhandleInvoke(Object receiver, MethodHandle method) throws Throwable {
         return (String) method.invoke(receiver, "methodhandle");
     }

or like that:

     private static final MethodHandles.Lookup lookup = MethodHandles.lookup();
     private static final MethodType mt = MethodType.methodType(String.class, String.class);
     private static final MethodType mt2 = MethodType.methodType(String.class, Object.class, String.class);

     private static MethodHandle methodhandleLookup(Object receiver, String methodName) throws Throwable {
         MethodHandle mh = lookup.findVirtual(receiver.getClass(), methodName, mt);
         return mh.asType(mt2);
     }

     private static String methodhandleInvoke(Object receiver, MethodHandle method) throws Throwable {
         return (String) method.bindTo(receiver).invokeExact(receiver, "methodhandle");
     }


Rémi

On 07/09/2011 12:01 PM, Jochen Theodorou wrote:
> Am 09.07.2011 10:48, schrieb Hiroshi Nakamura:
>> Hello,
>>
>> I heard that jsr292 makes dynamic method lookup&invocation faster than
>> reflection so I did some performance comparison against plain
>> reflection. I'm sending this mail since the result looks strange to
>> me.
>>
>> Code is here:
>> https://raw.github.com/nahi/jsr292-sandbox/master/src/jp/gr/java_conf/jruby/MethodHandleTest.java
> lookup I don't know. I am not sure about the recent versions, I think
> the lookup is using the same "core" as Reflection plus additional
> checks. I don't expect that to be faster. It would be very nice though.
>
> The performance of the invocation cannot be meassured like you do it I
> think. The big pro comes from the ability to inline the method calls,
> but this is only present if you use the invokedynamic bytecode
> instruction. There is currently no way in Java to express invokedynamic.
>
> And a third point... even if there where invokedynamic used, I think in
> your case it would not really bring forth the real performance
> possibilities, since your receiver is changing all the time.
>
> But in general I must say, I would have expected the performance to be
> at least near Reflection as well. I mean the situation is for Reflection
> not all that better.
>
> bye blackdrag
>