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>
