I have no idea! Le ven. 25 mai 2018 à 11:05, Jesper Steen Møller <jes...@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 <jes...@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 <cchamp...@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> > > > >
