groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cchamp...@apache.org>
Subject Re: Performance of the compiler
Date Fri, 25 May 2018 09:07:18 GMT
I have no idea!

Le ven. 25 mai 2018 à 11:05, Jesper Steen Møller <jesper@selskabet.org> a
écrit :

> 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?
>
> -Jesper
>
> > On 24 May 2018, at 10.08, Jesper Steen Møller <jesper@selskabet.org>
> 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, 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