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> >
