> 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 >
