blackdrag commented on PR #2852: URL: https://github.com/apache/groovy/pull/2852#issuecomment-5519131768
> On real applications: the numbers we have are still micros (`CachedMethod.invoke` in isolation, plus a short megamorphic row). They do not stand in for Grails, Gradle, or a long-lived Groovy service. I would not claim a wall-clock win there without a workload that keeps the same `MetaClass` method table hot. If you have a candidate app bench, I am happy to run `disable=true` against the default on it. The kill switch stays for anyone who would rather not generate. @daniellansun the problem I have is simple, what kind of program would use this path so extensively? If we talk about a long running program the threshold is reached, but it does not mean we are talking about a hot path. I guess that means we have to look for a tight loop, and the call must be dynamic from the Java side to an existing method, instead of calling the method directly. That means paths that go maybe through GroovyObject.invoke, InvokerHelper, MetaClass or CachedMethod itself. In Groovy itself we use most of these somewhere in extension methods usually. Maybe DynamicDispatchBench, especially the ones using MethodInterceptor could answer the question better. But my expectation is that the surrounding machinery shadows the actual call cost. We could also create another benchmark around ObjectRange, basically use the for-loop to iterate through it and cause a lot of dynamic "next" calls from Java world. Of course those are not real applications and just give indicators -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
