Hello, Thanks for you comments.
On Sat, Jul 9, 2011 at 19:01, Jochen Theodorou <blackd...@gmx.org> wrote: >> 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. Sure. I should have written it clearly. I heard from someone at Java SE 7 launch event that reflection would get faster on Java SE 7 even if you don't use dynamic language, so I wanted to measure the MethodHandle perf without invokedynamic. For invokedynamic, I did some (bogus, experimental, micro)benchmark with current JRuby. http://bit.ly/invokedynamic (Flash, Japanese) Please see the circle at the right edge of 5 circles. Invokedynamic support of JRuby is still experimental but it already outperforms existing optimization code for some microbenchmarks. Great job, Charles. Disclaimer: I'm one of a JRuby committer :) > 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. Sure. JRuby's current invokedynamic code checks receiver type with the test for guardWithTest if I understand correctly. Invokedynamic would not bring perf gain for my sample MethodHandleTest, but if naive MethodHandle invocation is slower than reflection, invokedynamic might be the way I thought. > 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. Agreed. I won't expect it to Java SE 7 GA though. Regards, // NaHi _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
