After experimenting with MethodHandles.collectArguments (given a hand-written collector function) versus my own logic (using folds and permutes to call my collector), I can confirm that both are roughly equivalent and better than MethodHandle.asCollector.
The benchmark linked below calls a lightweight core Ruby method (Array#dig) that only accepts an IRubyObject[] (so all arities must box). The performance of collectArguments is substantially better than asCollector. https://gist.github.com/headius/28343b8c393e76c717314af57089848d I do not believe this should be so. The logic for asCollector should be able to gather up Object subtypes into an Object[] subtype without an intermediate array or extra copying. On Thu, Mar 25, 2021 at 7:39 PM Charles Oliver Nutter <head...@headius.com> wrote: > > Well it only took me five years to circle back to this but I can > confirm it is just as bad now as it ever was. And it is definitely due > to collecting a single type. > > I will provide whatever folks need to investigate but it is pretty > straightforward. When asking for asCollector of a non-Object[] type, > the implementation will first gather arguments into an Object[], and > then create a copy of that array as the correct type. So two arrays > are created, values are copied twice. > > I can see this quite clearly in the assembly after letting things > optimize. A new Object[] is created and populated, and then a second > array of the correct type is created followed by an arraycopy > operation. > > I am once again backing off using asCollector directly to instead > provide my own array-construction collector. > > Should be easy to reproduce the perf issues simply by doing an > asCollector that results in some subtype of Object[]. > > On Thu, Jan 14, 2016 at 8:18 PM Charles Oliver Nutter > <head...@headius.com> wrote: > > > > Thanks Duncan. I will try to look under the covers this evening. > > > > - Charlie (mobile) > > > > On Jan 14, 2016 14:39, "MacGregor, Duncan (GE Energy Management)" > > <duncan.macgre...@ge.com> wrote: > >> > >> On 11/01/2016, 11:27, "mlvm-dev on behalf of MacGregor, Duncan (GE Energy > >> Management)" <mlvm-dev-boun...@openjdk.java.net on behalf of > >> duncan.macgre...@ge.com> wrote: > >> > >> >On 11/01/2016, 03:16, "mlvm-dev on behalf of Charles Oliver Nutter" > >> ><mlvm-dev-boun...@openjdk.java.net on behalf of head...@headius.com> > >> >wrote: > >> >... > >> >>With asCollector: 16-17s per iteration > >> >> > >> >>With hand-written array construction: 7-8s per iteration > >> >> > >> >>A sampling profile only shows my Ruby code as the top items, and an > >> >>allocation trace shows Object[] as the number one object being > >> >>created...not IRubyObject[]. Could that be the reason it's slower? > >> >>Some type trickery messing with optimization? > >> >> > >> >>This is very unfortunate because there's no other general-purpose way > >> >>to collect arguments in a handle chain. > >> > > >> >I haven¹t done any comparative benchmarks in that area for a while, but > >> >collecting a single argument is a pretty common pattern in the Magik code, > >> >and I had not seen any substantial difference when we last touched that > >> >area. However we are collecting to plain Object[] so it might be that is > >> >the reason for the difference. If I¹ve got time later this week I¹ll do > >> >some experimenting and check what the current situation is. > >> > >> Okay, I’ve now had a chance to try this in with our language benchmarks > >> and can’t see any significant difference between a hand crafted method and > >> asCOllector, but we are dealing with Object and Object[], so it might be > >> something to do with additional casting. > >> > >> Duncan. > >> > >> _______________________________________________ > >> mlvm-dev mailing list > >> mlvm-dev@openjdk.java.net > >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net https://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
