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 >> firstname.lastname@example.org >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list email@example.com https://mail.openjdk.java.net/mailman/listinfo/mlvm-dev