groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesper Steen Møller <>
Subject Re: Performance of the compiler
Date Fri, 25 May 2018 09:05:32 GMT
Oh - I see now that this is implemented already (optimizationOptions w/asmResolvingin:true).
Is there any reason this is not the default? Is it slower? Incorrect?


> On 24 May 2018, at 10.08, Jesper Steen Møller <> wrote:
> Interesting! So let me get this straight: Are we using an actual "in-JVM" classloader
to load classes examined by the Groovy Compiler itself?
> In the Eclipse Java compiler, we don't actually load the classes into the JVM, instead
we have our own implementation of classpath traversal and read it using ClassFileReader. Would
a similar approach not work for constructing ClassNodes in Groovy? (obviousluy using ASM to
do the bytecode parsing instead of rolling it ourselves).
> JPMS would naturally make complicate things further, but again, ECJ has cracked this,
> -Jesper
>> On 24 May 2018, at 08.30, Cédric Champeau <> wrote:
>> Hi folks,
>> I just wanted to share the result of profiling the performance of the compiler on
"real world" classes, namely compiling the tests of Gradle. We have a lot of tests, so compilation
times becomes really a pain point, so I have checked where we spend time. I have attached
the export of hotspots from a real compilation session.
>> It's no surprise to me, most of the time (70%) is spent in the resolve visitor, and
most of this time itself is spent in loading classes. We made some improvements in the past,
by not initializing those classes, but it's still a crazy amount of time.
>> Similarly, we spend around 10% of our time in filling stack traces which are used
for flow control. Unfortunately we don't have the opportunity to change this because it's
either ClassNotFoundException (during resolution) sent by the classloader, or ANTLR recognition
exception, used for flow control (duh!).
>> I remember that for Gradle I had implemented a custom ResolveVisitor that adds some
assumptions for Gradle scripts to avoid too many lookups for classes which would obvisouly
not exist, and it significantly improved the performance of compiling scripts, but that was
because there were lots of implicit imports. For regular classes I'm not sure it's as simple.
>> Resolution is also very easy to break... Anyway, any change in this area would probably
make the lives of our users better!
>> <CPU-hot-spots.txt>

View raw message