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
