speed of invokeExact
Jochen Theodorou
blackdrag at gmx.org
Fri May 10 01:37:45 PDT 2013
Am 10.05.2013 02:40, schrieb Christian Thalinger:
[...]
> That's because your method handle is not constant and so the compiler cannot inline the call.
And you tell me that in the first case the call was inlined? That is
unexpected. And if that is the case, then why does this:
>>> MethodHandle mh = MethodHandles.lookup().findVirtual(String.class, "toString", MethodType.methodType(String.class));
>>> MethodType invokeType = MethodType.methodType(Object.class, String.class);
>>> int tmax = 1_000_000;
>>> for (int k=0; k<20; k++) {
>>> long t1 = System.nanoTime();
>>> for (int i=0; i<tmax; i++) {
>>> MethodHandle invoker = mh.asType(invokeType);
>>> }
>>> long t2 = System.nanoTime();
>>> System.out.println((t2-t1)/tmax);
>>> }
take that long as well? Maybe it changed, but I thought only handles
coming from a final field are constant enough for inlining. If I compare
to 1.7.11 (or 1.7.6) then I get around 23 for the first, and 200-300 for
the second and third test. That is about a factor 10-15 slowdown, that
is what I would expect from the call not being inlined for example. But
I always thought 1.7 will not inline in this case at all. On my 1.8 it
was almost a factor 100. So unless the noninlined call on a method
handle got extremely expensive compared to 1.7, there must be something
else too.
bye blackdrag
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
More information about the mlvm-dev
mailing list