Tens of thousands of tests, and ~4 minutes compile time (with --parallel). Le ven. 25 mai 2018 à 14:50, mg <mg...@arscreat.com> 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 <cchamp...@apache.org> > Datum: 24.05.18 08:30 (GMT+01:00) > An: dev@groovy.apache.org > 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! > > >
