groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <>
Subject Re: Performance of the compiler
Date Fri, 25 May 2018 13:03:07 GMT
Tens of thousands of tests, and ~4 minutes compile time (with --parallel).

Le ven. 25 mai 2018 à 14:50, mg <> a écrit :

> Hi Cedric,
> to put this in context and to better understand the ongoing discussion:
> How many tests and what absolute compile time are we talking about here ?
> Cheers,
> mg
> -------- Ursprüngliche Nachricht --------
> Von: Cédric Champeau <>
> Datum: 24.05.18 08:30 (GMT+01:00)
> An:
> Betreff: Performance of the compiler
> 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!

View raw message