[
https://issues.apache.org/jira/browse/GROOVY-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573420#comment-17573420
]
Paul King commented on GROOVY-10709:
------------------------------------
I did a quick prototype to see if there were any quick wins from tweaking our
current solution.
This was just for the "GroovyObjectHelper #findGetLookupMethod, #doLookup" part
which Jochen mentioned.
JMH gave the following results:
{noformat}
4.0.4
Result "groovyjmh.Main.test":
33.810 ±(99.9%) 0.222 us/op [Average]
(min, avg, max) = (33.326, 33.810, 35.733), stdev = 0.448
CI (99.9%): [33.589, 34.032] (assumes normal distribution)
4.0.5-SNAPSHOT
Result "groovyjmh.Main.test":
34.927 ±(99.9%) 0.249 us/op [Average]
(min, avg, max) = (34.340, 34.927, 37.134), stdev = 0.504
CI (99.9%): [34.678, 35.177] (assumes normal distribution)
4.0.5-SNAPSHOT with metaClass getMetaMethod guard
Result "groovyjmh.Main.test":
33.688 ±(99.9%) 0.274 us/op [Average]
(min, avg, max) = (32.894, 33.688, 35.875), stdev = 0.554
CI (99.9%): [33.413, 33.962] (assumes normal distribution)
4.0.5-SNAPSHOT with metaClass respondsTo guard
Result "groovyjmh.Main.test":
33.567 ±(99.9%) 0.242 us/op [Average]
(min, avg, max) = (33.072, 33.567, 35.825), stdev = 0.490
CI (99.9%): [33.324, 33.809] (assumes normal distribution)
4.0.5-SNAPSHOT with cache
Result "groovyjmh.Main.test":
34.066 ±(99.9%) 0.219 us/op [Average]
(min, avg, max) = (33.579, 34.066, 35.631), stdev = 0.442
CI (99.9%): [33.847, 34.285] (assumes normal distribution)
{noformat}
I don't know why 4.0.4 was slightly quicker but the three tweaks I did were
very slightly faster than 4.0.5-SNAPSHOT without tweaks. It is quite possible I
didn't scale my microbenchmark enough for the changes to make much difference.
The benchmark was micro. I had 5 classes with 5 methods each all returning an
int. There were also 5 types of classes used: Java, Java extending
GroovyObject, Groovy 3 classic bytecode, Groovy 3 indy bytecode, and Groovy 4.
I'd expect the first and last to work fine for the current logic but the others
to fail and bubble up to the outer fallback. All 5 methods of all 5 classes
from all 5 scenarios were added together from both dynamic and static code. I
did 5 warmup iterations and 50 normal iterations.
The first two tweaks used the object in question's metaClass one calling
getMetaMethod(), the other respondsTo() as guards before attempting the
getDeclaredMethod() call. I was expecting using the metaclass might be an
expensive operation the first time it was called but hoped some caching might
then come into play. I think there might be better things we could do if we
check that we have a MetaClassImpl metaClass but that wasn't tested.
The last tweak was to use a {{ConcurrentSkipListSet}} to keep track of failed
lookups and not bother subsequent calls. My gut feel is that there may not be
huge wins here but I am happy to run bigger benchmarks or publish a snapshot if
needed.
> Performance regression in Gradle with Groovy 4
> ----------------------------------------------
>
> Key: GROOVY-10709
> URL: https://issues.apache.org/jira/browse/GROOVY-10709
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.3
> Reporter: Kyle Moore
> Priority: Major
> Attachments: test-results-largeAndroidBuildPerformanceAdHocTest.zip
>
>
> The Gradle team is exploring Groovy 4 as the included version for our next
> major release.
> Our initial performance tests show a significant regression which may be
> caused by excessive method calls to generate specialized exceptions that
> don't have stacks.
> I will attach a tome of performance data comparing Gradle built with Groovy
> 3.0.11 vs. 4.0.3. Interesting measurements are available at:
> *
> run-help/7.6-20220727093039+0000/diffs/run-help-7.6-20220727093039+0000-vs-7.5-cpu-simplified-backward-diff-flames.svg
> * performance-tests/report/index.html -> comparing "Gradle 7.5" vs. "Current
> Gradle" shows a significant regression.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
