[
https://issues.apache.org/jira/browse/GROOVY-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18063213#comment-18063213
]
ASF GitHub Bot commented on GROOVY-10307:
-----------------------------------------
jamesfredley commented on PR #2374:
URL: https://github.com/apache/groovy/pull/2374#issuecomment-4004854328
These changes significantly improve
https://github.com/jamesfredley/grails7-performance-regression results on
Groovy 4, but these changes were not positive on Groovy 6 (master) which has
already had dozens of indy related changes.
I have created a PR to backport the JMH benchmarks from master to 4:
https://github.com/apache/groovy/pull/2393
When I ran these benchmarks against Groovy 4 with and without this PR:
What improved: Benchmarks with metaclass churn - burstThenSteadyState
(-64%), multiClassStartupThenSteadyState (-61%), invalidation benchmarks (-6%
to -20%). These are scenarios where SwitchPoint invalidation is the bottleneck.
What regressed: Steady-state benchmarks where no invalidation happens -
baselineHotLoop (+17%), baselineListSize (+16%), baselineCollectionClosureChain
(+17%), baselineProjectMetrics (+17%). The call site registry overhead hurts
when there's nothing to invalidate.
This matches the pattern: disabling SwitchPoint helps during metaclass churn
but adds overhead on the normal hot path. Whether it's net positive depends on
workload mix and how much JIT warmup you give it.
https://github.com/jamesfredley/grails7-performance-regression showed a 2x
improvement, but the JMH tests show a less positive picture. The grails
performance test did not appear to allow for consistent or full JIT warmup. I
am now not sure that this PR is a good idea for Groovy 4 overall. Maybe only
as non-default and enabled with a flag that Grails 7 would use, but Grails 7
EOL is June 30th, so I am not sure that is worth the effort.
`groovy.indy.switchpoint.guard=true by default`
> Groovy 4 runtime performance on average 2.4x slower than Groovy 3
> -----------------------------------------------------------------
>
> Key: GROOVY-10307
> URL: https://issues.apache.org/jira/browse/GROOVY-10307
> Project: Groovy
> Issue Type: Bug
> Components: bytecode, performance
> Affects Versions: 4.0.0-beta-1, 3.0.9
> Environment: OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9
> (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)
> WIN10 (tests) / REL 8 (web application)
> IntelliJ 2021.2
> Reporter: mgroovy
> Priority: Major
> Attachments: groovy_3_0_9_gc.png, groovy_3_0_9_loop2.png,
> groovy_3_0_9_loop4.png, groovy_3_0_9_mem.png, groovy_4_0_0_b1_loop2.png,
> groovy_4_0_0_b1_loop4.png, groovy_4_0_0_b1_loop4_gc.png,
> groovy_4_0_0_b1_loop4_mem.png,
> groovysql_performance_groovy4_2_xx_yy_zzzz.groovy, loops.groovy,
> profile3.txt, profile4-loops.txt, profile4.txt, profile4d.txt
>
>
> Groovy 4.0.0-beta-1 runtime performance in our framework is on average 2 to 3
> times slower compared to using Groovy 3.0.9 (regular i.e. non-INDY)
> * Our complete framework and application code is completely written in
> Groovy, spread over multiple IntelliJ modules
> ** mixed @CompileDynamic/@TypeChecked and @CompileStatic
> ** No Java classes left in project, i.e. no cross compilation occurs
> * We build using IntelliJ 2021.2 Groovy build process, then run / deploy the
> compiled class files
> ** We do _not_ use a Groovy based DSL, nor do we execute Groovy scripts
> during execution
> * Performance degradation when using Groovy 4.0.0-beta-1 instead of Groovy
> 3.0.9 (non-INDY):
> ** The performance of the largest of our web applications has dropped 3x
> (startup) / 2x (table refresh) respectively
> *** Stack: Tomcat/Vaadin/Ebean plus framework generated SQL
> ** Our test suite runs about 2.4 times as long as before (120 min when using
> G4, compared to about 50 min with G3)
> *** JUnit 5
> *** test suite also contains no scripts / dynamic code execution
> *** Individual test performance varies: A small number of tests runs faster,
> but the majority is slower, with some extreme cases taking nearly 10x as long
> to finish
> * Using Groovy 3.0.9 INDY displays nearly identical performance degradation,
> so it seems that the use of invoke dynamic is somehow at fault
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
