Groovy - invoke dynamic performance problems

[jglapa]

Issue description

We upgraded a large and data-intensive application from Grails 6.2.3 to Grails 7 but noticed a significant performance regression reaching 4x on some operations.

We suspect this is related to Groovy 4's "indy" approach and GORM suffering from that more than expected.

It's not noticeable at first sight. I couldn't come up with a simple example where such a big regression would be noticeable so I ended up using an LLM to generate a small application with a method doing something on the data using GORM.

It's a bunch of domains (Company, Department, Employee, Milestone, Project, Skill, Task) with associations and an initial dataset. Uses H2 dev database for simplicity.

I really hope I haven't missed anything obvious (some optimisation or flag, hibernate cache is disabled in both) and this is indeed a Groovy 4 regression.

• With 50 iterations (and 5 warmup iterations) I observed the same 4x regression.
• with -Dgroovy.indy.optimize.threshold=0 -Dgroovy.indy.fallback.threshold=0 it's only ~2x as bad but it's not entirely clear how to use that, other combinations didn't yield results as good
• when looking at flame graphs unsurprisingly Grails 7 is full of org.codehaus.groovy.vmplugin.v8.* where Grails 6 is using org.codehaus.groovy.runtime.*
• @CompileStatic hasn't been explored as it requires code changes that I would really like to avoid
• benchmarks were done with :bootWar, embedded tomcat with -Dgrails.env=development but :bootRun is 8x slower than Grails 6, and 3x slower than Grails 7 bootWar - so development mode in IDE is also hit

At the moment we've had to stop and revert the migration as a 4x performance hit is hard to swallow.

From groovy4: https://groovy-lang.org/releasenotes/groovy-4.0.html#Groovy4.0-consolidation

Currently, the Groovy runtime still contains any necessary support for classes compiled using older versions of Groovy. Please use Groovy versions up to 3.x if you need to generate the older style bytecode.

This work was originally planned for Groovy 3.0, but there were numerous places where "indy" code was noticeably slower than "classic" bytecode. We have made numerous speed improvements (starting with [GROOVY-8298](https://issues.apache.org/jira/browse/GROOVY-8298)) and have some ability to tune internal thresholds (search the code base for groovy.indy.optimize.threshold and groovy.indy.fallback.threshold). That work gave us useful speed improvements, but we welcome further feedback to help improve overall performance of the indy bytecode.

Is there any chance this can be further optimised or could Grails 7 potentially work with Groovy 3?

Link to the benchmark applications: https://github.com/jglapa/grails7-performance-regression

[jdaugherty]

To revert the invokedynamic changes (still allowed for Groovy 4), you can use:

tasks.withType(GroovyCompile).configureEach {
    groovyOptions.with {
        optimizationOptions.indy = false
    }
}

in your build.gradle. You're right that it's a significant performance hit. I've had similar experiences in a large Grails 7 application, disabling indy was my only choice to restore performance. I have noticed the JVM upgrades making these performance hits less noticeable.

Similar discussions that may be of benefit:

1. https://lists.apache.org/thread/q257zbtvm0jgnr5gqojfcpphlfpoos94
2. https://lists.apache.org/thread/n9c055nw1mwtnvmlgqsk5jlfov6vgrky

[jdaugherty]

As to your Groovy 3 question, we can't make Grails 7 work with Groovy 3 because it uses older, conflicting libraries. The best option is to disable off invoke dynamic. Can you please test your benchmarks with this configuration and let us know of the performance? I suspect Groovy 5 will be the real issue when that feature goes away.

[jglapa]

@jdaugherty Amazing! I wasn't aware that indy could still be disabled with Groovy 4.

I can confirm that in both my benchmark and the application, performance is back on par with Grails 6/Groovy 3, allowing us to continue with the upgrade.

Benchmark Results

Test Type	Grails 6	Grails 7 (indy)	Grails 7 (no indy)
bootWar	61.18 ms	323.48 ms	64.24 ms
bootRun	103.96 ms	858.00 ms	115.12 ms

Additional Notes

PS: I tried the indy version with Java 21, and that didn't show any difference. I would be skeptical that JVM upgrades will address such a significant performance gap.

PS2: Is the Grails team in touch with the Groovy maintainers? Are they aware of this issue? It's unclear who would choose the indy version at the moment or in the future..

[jdaugherty]

Thank you @jglapa.

Concerning newer versions, I was more speaking about the general performance gains from 11 -> 17 helped offset this pain in the past. I suspect the jump to 25 will be even more significant.

Concerning the Groovy maintainers, yes. The chair of the Groovy PMC is actually on the Grails PMC. I'll bring this up in our weekly meeting to try to bring it more into focus.

[jdaugherty]

I'm going to reopen this and pin it as a ticket so other people have awareness of this. I'm also going to use this ticket to discuss the performance problems in relation to Groovy.