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!
