Hi Daniel,
could you confirm that with my sample ? I have tried all the
optimization settings when you proposed them before
("-Dgroovy.indy.optimize.threshold=0" threw an NPE, but
"-Dgroovy.indy.optimize.threshold=2" should lead to the same result as
far as I understand), and that alas did not lead to the performance of
Groovy 3... (see performance tables in
https://issues.apache.org/jira/browse/GROOVY-10307)
But I would be happy to learn I did something wrong, and this problem
does indeed have such a simple solution, so it would be great if you
could try your optimizations with my sample, to confirm that they indeed
lead to the performance Groovy 3 exhibits :-)
Cheers,
mg
On 07/05/2022 18:12, Daniel Sun wrote:
Hi mg,
Groovy 4 enables indy, i.e. invokedynamic by default, and the default threshold for
optimization of indy is 10,000. We can adjust its value by the system property
"groovy.indy.optimize.threshold", e.g. "-Dgroovy.indy.optimize.threshold=0".
When the related code is executed more than threshold, the optimization will be applied, and the
performance will be better.
BTW, the optimization is double-edged sword, which **may** result in de-opt storm, in
other word, optimize -> de-optimize -> optimize -> de-optimize -> ... ->
optimize. As we can see, the de-opt storm will result in very very poor performance. In order
to solve the de-opt storm issue, the threshold for optimization is introduced and its default
value is 10,000.
Cheers,
Daniel Sun
On 2022/05/06 23:55:19 MG wrote:
Hi Groovy devs,
I have finally managed to extract a sample from our Groovy framework
that only uses our most basic modules and still exhibits the 2-3x
performance degradation between (non-indy) Groovy 3 and Groovy 4 I
already described in multiple posts a while ago.
The code was built using the latest Groovy releases (3.0.10 / 4.0.1),
you can find the 2 JARs & a test script at:
https://github.com/mgroovy/groovyperformance/tree/trunk/groovy4_performance_public_sample
To check the performance:
1. Open a GroovyConsole window for Groovy 3.0.10
2. Do Script\Add JAR(s) to ClassPath: groovyperformance-3.0.10.jar
3. Load & execute groovysql_performance_groovy4_2_xx_yy_zzzz.groovy
Analogue for Groovy 4.0.1 with groovyperformance-4.0.1.jar.
On 3 different PCs I consistently get results as shown below (each timed
test step executes the same code 100x, each time creating the same
simple SQL GString using our framework):
*Groovy 3.0.10*
0) dt = 7.99 ms
1) dt = 2.01 ms
2) dt = 1.53 ms
3) dt = 1.65 ms
4) dt = 1.36 ms
*Groovy 4.0.1*
0) dt = 16.51 ms
1) dt = 7.14 ms
2) dt = 5.83 ms
3) dt = 6.6 ms
4) dt = 6.24 ms
Throwing away the first loop, which includes framework setup time,
Groovy 3 outperforms Groovy 4 by a factor of about 3 (Note: On my
notebook the factor is closer to 2).
Execution times generally decrease when starting the script multiple
times, but the best dt I have observed on the PC the above measurements
were taken was 3.3ms, whereas Groovy 3.0.10 goes down below 1ms (In any
case this is irrelevant for practical applications, since here a short,
identical code segment will not be executed n x 500-times in a loop).
The performance degradation exhibited here is consistent with the
performance of a) executing our test suite and b) startup & refresh
cycle measurements I did in a web application based on our framwork
code, as described before.
I did not get anywhere trying to use VisualVM trying to pinpoint where
exactly performance was lost, apart from what I described in a previous
post.
Groovy 3 exhibits the same performance degradation when used in indy
mode, so it seems logical to assume that this mechanism is somehow to blame.
Based on this observation I tried to refactor parts of our framework
which create a lot of new objects / do a lot of method calls, but even
short-circuiting these did not lead to any relevant change in performance.
So this is hoping this finally supplies the information that leads to a
solution to this problem by someone that has knowledge about the inner
workings of Groovy & the JVM invokedynamic mechanism, and un-bars us
from ever switching to Groovy 4 G-)
Cheers,
mg
