[
https://issues.apache.org/jira/browse/GROOVY-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17572550#comment-17572550
]
Jochen Theodorou commented on GROOVY-10709:
-------------------------------------------
Looking at GroovyObjectHelper #findGetLookupMethod, #doLookup, #lookup.... It
seems we are trying to find a lookup method on a class that implements
GroovyObject, but is not compiled by Groovy, thus has no $getLookup method.
Actually I think we need to improve this code part. We have a lot of classes
implementing GroovyObject, that do not have that method, because they are
written in Java. And I guess in the case of Grails that is even more. For
example can the MetaClass contain that information. I would not even go the
path of GroovyObjectHelper.lookup.
If that fixes the performance issue.. no idea, but it seems to contribute and
plays a factor
> 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)
