typetools
Compilation time doubling in Hibernate ORM
After reading https://groups.google.com/g/checker-framework-discuss/c/pLYydnOjZak/m/s2ooHiHbAQAJ i.e.
It has to do all the same work as the compiler does, such as resolving overloading and overriding, inferring generics, and type-checking.
It starts to make sense to me why using checkerframework roughly doubles compilation times.
The Hibernate ORM project is now considering to disable the checkerframework by default and only run it on CI, because it slows down our day-to-day work.
Are there any potential improvements that can reduce this overhead in the future? Or is this simply a consequence of not being able to modify the compiler directly?
We only use the NullnessChecker and I would like to understand if there might be a way to reduce the overhead of this particular analysis. Or maybe you have suggestions for alternatives since nullness analysis is the only thing we care about?
Thanks in advance!
I'm sorry about the slow performance, and that it's impacting your development experience. Improving the run time is not a high priority for us right now, due to limited resources.
I personally find running checkers to be tedious for complete project compilation, but that should be rare. Running checkers is quite tolerable for incremental compilation, which is what happens during my typical work. Unfortunately, many build systems disable incremental compilation whenever an annotation processor is running, because it's possible for an annotation processor to create new code. (The Checker Framework never does this, but I don't know how to communicate this fact to build systems.) I believe that fixing the problem with build systems would have much more impact than speeding up the Checker Framework itself. If you know anyone with expertise in build systems and can nudge them about this issue, that would be great.
(Here is a hack that just occurred to me. Do incremental compilation as usual, without the Checker Framework. Determine which files were compiled, and then run the Checker Framework on only those files.)
In the meanwhile, it is reasonable to enable the Checker Framework in CI -- especially if CI runs on every push to every branch. That's what I do when I have a large project that uses a build system that cannot do incremental compilation in the presence of annotation processors.
We actually do have incremental compilation enabled and use this Gradle plugin to make checkerframework work with that. I also verified that incremental compilation works correctly, but still, checkerframework simply doubles compilation time, so what I wrote and asked about is still relevant.
For debugging what makes checkerframework slow, you can also use the -AslowTypecheckingSeconds option introduced in #7066 (it is available in the latest release but I think not actively mentioned in the release notes as it mitigated but not fixed an issue). e.g. if you add -AslowTypecheckingSeconds=1 (or similar) to the javac arguments, it will tell about specific parts of your code that take more than one second to process. If you notice a method making heavy use of lambdas taking a long time that way, you could try splitting that method.
Thanks for the suggestion, but I'm having a hard time justifying the use of checkerframework within my team already, so doing/requiring any further changes to our code is just going to lead to more resistance 😅
Can anyone answer my initial questions? Or does
Improving the run time is not a high priority for us right now, due to limited resources.
roughly mean that "it is how it is, sorry, but we have no plans to improve it and there is no suggestion we can make"?