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.r...@oracle.com> > À: "Claes Redestad" <claes.redes...@oracle.com>, "Stephen Colebourne" > <scolebou...@joda.org> > Cc: "jigsaw-dev" <jigsaw-dev@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.redes...@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
