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
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
Ch
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
> 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, w
Hi Paul & Jochen.
I have uploaded some repeated test execution timings & VisualVM hot spot
screenshots from a suitable looking test, comparing Groovy 3.0.9
(non-INDY) with Groovy 4.0.0-beta-1:
https://issues.apache.org/jira/browse/GROOVY-10307
Cheers,
mg
On 15/10/2021 10:21, Paul King wrot
Thanks for the clarification. I didn't fully understand your scenario. Both
parsing and the Indy bytecode have been areas where we've had feedback
about performance. A bunch of projects have been impacted by both. In your
case it will be bytecode improvements that are needed. We have made some
good
Hi Paul & Stephen,
unless I am missing something some miscommunication seems to have
happened: We compile our complete framework and application code (all
written in Groovy, mixed @CompileDynamic/@TypeChecked and
@CompileStatic) using IntelliJ Groovy build process, then run / deploy
the compi
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
I've seen similar problems with Groovy 3.x/4.x when upgrading Apache
TinkerPop (we've had to revert from it to 2.5.x and without an improvement
I don't see how upgrade will be possible in the future). I had a specific
context we were dealing with in groovysh but I sense it is not limited
there. I d
Hi mg,
Antlr4 performance is something we want to work much more on but it isn't
an easy task and we have already picked off some of the low-hanging fruit.
It is probably worth creating a Jira ticket for this. We tend to progress
much more efficiently on well-defined issues than broad ones, but p
Hi,
we have spiked using Groovy 4.0.0-beta-1 with our Groovy framework, to
see if the GString improvements would lead to a speedup in our SQL
generation code (typically this is irrelevant, and performance is solely
decided by SQL optimizations, but we have recently come across a few
cases in
11 matches
Mail list logo
