groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesper Steen Møller <jes...@selskabet.org>
Subject Re: Performance of the compiler
Date Thu, 24 May 2018 08:08:01 GMT
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, too.

-Jesper

> On 24 May 2018, at 08.30, Cédric Champeau <cchampeau@apache.org> 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>


Mime
View raw message