MethodHandle performance

[Remi Forax]

The problem is more that if you have played a little with the API, you know that invokeWithArguments is slow because it may do a lot of work with no way to cache the intermediary representation into the user code (and even if you add a cache, it will not handle all the cases, if the arrays do not have the same size or if the signature of the mh is not generic, etc). 

I think we (the JSR 292 EG) have failed here, we should not have introduced a method which is perhaps too convenient but hard to optimize.

Why not adding a line in the javadoc of invokeWitharguments, saying something like this:
Don't expect invokeWithArguments to be fast! Use invokeExact or invoke if you need performance.

cheers,
Rémi

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Claes Redestad" <claes.redestad at oracle.com>, "Stephen Colebourne" <scolebourne at joda.org>
> Cc: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Vendredi 13 Janvier 2017 20:04:20
> Objet: Re: MethodHandle performance

> On Jan 12, 2017, at 12:29 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
>> 
>> Right, I was just looking at the micro Stephen provided me, and it does
>> seem that the added cost for this case is due to invokeWithArguments
>> creating a new invoker every time.
> 
> This is a good workaround, and Stephen's report is a helpful reminder
> that our performance story has a sharp edge.
> 
> We cache spreaders in the case of varargs methods,
> for full performance, but not for the ad hoc spreader used by MH.iWA.
> 
> We should cache them, to remove this sharp edge (or performance pothole).
> There are small technical challenges to do so.  Claes and I added
> some notes to the bug report; maybe someone can look into it more.
> 
> — John