1. I have already tested with -Dgroovy.indy.optimize.threshold=2
-Dgroovy.indy.callsite.cache.size=4 two days ago (see ticket): The
memory consumption is higher, while speed is increased (but still
much slower than Groovy 3)
2. I have just tested with the build under
https://github.com/apache/groovy/actions/runs/1375230234, and the
results are basically unchanged (did therefore not upload
screenshots to ticket)
Cheers,
mg
On 26/10/2021 18:02, Daniel Sun wrote:
groovy.indy.callsite.cache.size can control the size of PIC, e.g.
-Dgroovy.indy.callsite.cache.size=4
Also, here is a snapshot to reduce the memory usage, if you could give it a
try, and give us some feedback, that would be appreciated.
https://github.com/apache/groovy/actions/runs/1375230234
Cheers,
Daniel Sun
On 2021/10/24 17:41:22 MG wrote:
Hi Daniel,
I have updated the ticket with some VisalVM memory sampling screenshots:
For this short test Groovy 4 uses more than 13 million objects of type
java.util.concurrent.atomic.AtomicReference, together with an more than
100,000 java.util.concurrent.atomic.AtomicReference[] arrays, which
together makes up about 36% of memory consumption. The overall memory
consumption is nearly 3x as high for Groovy 4: 1.2 GB vs 0.46 GB for
Groovy 3 (heap size: 8 GB)
That seems a lot to me - would you expect these numbers to be influenced
by any of the JVM settings you proposed ?
https://issues.apache.org/jira/browse/GROOVY-10307
Cheers,
mg
On 24/10/2021 18:29, Daniel Sun wrote:
What I can tell you for sure is, that invokedynamic has a big problem with
1-time calls. It is much more expensive to generate the callsite for
invokedynamic than it is for our old callsite code (which will stop working)
and also of course compared to direct method calls.
In addition, when method is called over 100000 times by default, the method
will be set as target to the indy call site, so 1-time calls can not benefit
from optimization of the indy call site.
P.S. the default threshold(100000) mentioned above can be changed by setting JVM option
"groovy.indy.optimize.threshold", e.g. `-Dgroovy.indy.optimize.threshold=100`
Cheers,
Daniel Sun
On 2021/10/14 11:48:47, Jochen Theodorou<blackd...@gmx.org> wrote:
On 14.10.21 01:24, MG wrote:
[...]
Alas performance-wise what we surprisingly found was, that the
performance of our main web application dropped by a factor of 2 (table
refresh) to 3 (startup).
Executing our test suite showed a similar picture. Since no immediate
source for this performance drop emerged, we checked the performance of
Groovy 3 Indy, more to rule out that the performance reduction had
something to do with invokedynamic;
as can be seen in the table below, to our surprise performance
degradiation of Groovy 3.0.9 with full invokedynamic (Groovy JARs &
IntelliJ compiler switch/checkbox active) was in fact in most cases
close to the one seen with Groovy 4.0.0-beta-1, pointing to
invokedynamic as the potential cause.
Right now it looks to us, as if Groovy with invokedynamic for us is just
"leaking performance everywhere", with no clear source.
Speed changes range from about 0.6 (i.e. a speedup) to about 5.0, with a
large bias towards a slowdown by a factor of 2.0 to 2.5. The overall
time of the test suite increased by a factor of 2.37 (G3 Indy) and 2.45
(G4) respectively.
Any ideas what could be the cause of this unexpected slowdown or where
we should put our focus in analyzing this, to create a test case
independent of our framwork ?
Unless someone here has a concrete candidate it will be difficult to
find out what exactly the problem is without having the code itself I
guess.
What I can tell you for sure is, that invokedynamic has a big problem
with 1-time calls. It is much more expensive to generate the callsite
for invokedynamic than it is for our old callsite code (which will stop
working) and also of course compared to direct method calls.
By the nature of performance tests, this is rarely measured though and I
don't believe that this is causing the problem here.
A profiler, that profiles also the Groovy runtime code, could maybe show
code from the indy part, that is involved a lot and maybe should not.
If I would have no clue what this really could be I would actually do
the following.. I would turn on the hotspot compilation tracing,
printing me the machine code it produces and of which methods. Then I
would compare.... what methods are not compiled in indy? These are
candidates for being significant.
I am curious to see what others suggest
bye Jochen
