We slow our build down by having a dozen 'tools'-projects with a handful of classes each in a straight dependency-line above our main project that contains 99% of the code. This easily increases our compile time from a few seconds to several minutes. With a bonus chance to cause an infinite IDE workspace build loop.
That's a nice writeup. Given the hot/cold difference you observe, I'd be very curious to see how builds compare when using maven daemon or gradle daemon.
I am not very familiar with those myself, simply aware of them.
* compile/install jar only, skip source/javadoc packages
* checkstyle only
* static analysis only
* code coverage only
* Skip PGP (you DO check your artifact signatures, right?)
The beauty of this is you can create a corporate super pom that defines all of these for you and they can be inherited by every project in your org.
Finally, if you have a large multi-module project, run with -T2C to parallel-ize module builds. If your tests are written in a sane/safe manner: -DuseUnlimitedThreads=true -Dparallel=classes -DforkCount=2C will also give you a major boost.
We have a giant code base (500,000 SLOC) with 28 maven modules, and a full compile and install takes less 40 seconds with compile/install only. You often don't need to do a full build, but even with tests thats about 3 mins on a M3 Max.
I don't think anyone checks their artifact signatures. I've changed signatures several times over the past few years (every time I get a new laptop I forget to copy over my keys) and haven't heard a peep from anyone using my open source libraries who actually noticed the change
I think thats the major issue I have with Gradle in large orgs: it doesn't lend itself to reuse, but I don't blame it either: it's not really meant to do that.
I'm dating myself, but 20 years ago, we had Ant. It was very much a blunt hammer like CMake. Maven came along and was like "how about we choose a definitive way to organize projects, make that repeatable". You lose flexibility but gain speed/reuse.
I see Gradle more of a replacement for Ant than Maven in this regard. Infinite flexibility, at the cost of speed/reuse.
"From this study we can see the paradox: the Java compiler is blazing fast, while Java build tools are dreadfully slow."
Hi, nice article! I wholeheartedly agree with the conclusion after 10 years of fighting with maven for performance gains (that I always measured in minutes not seconds).
Interesting read. Just one remark to the "Keeping the JVM Hot" Benchmark:
Running the same Compilation Task on exactly the same input over and over again gives the Just in Time compiler of your Java runtime engine the chance to optimize for this specific task. This somehow spoils the idea of this benchmark because in a real world situation the source code changes between each compilation process.
Seems easy enough to do a quick fix for. Just add a option to maven that goes straight into compile and does nothing else. Would be good for local dev. However as we all know maven does much more than this and server side ci/cd process is what really slows your other team members down (if its slow)
Compiled means it's a direct executable in machine code. Java ain't that. Heck, if it needs a runtime with a garbage collector built into the runtime it's especially junk.
No, that is not what compiled means. A compiler is simply a program that translates from one language to another. Hence a compiled language is one that is translated into a different language prior to execution. Java is compiled twice; once to byte code and again to machine code by the JIT compiler. That is unless you compile it directly to machine code using, say, Graal Native Image.
You are welcome to your opinion on the utility of garbage collection but the widespread usage of GC suggests the industry as a whole does not share your view nor is such an unnaunced view supported by research (e.g. https://dl.acm.org/doi/abs/10.1145/1094811.1094836)
As having a masters in computer science I respectfully disagree with you. Would you consider a program that translates C code to FORTRAN a compiler? Nope, it's a translator. A compiler compiles a language into a direct executable. Just like Microsoft Windows has executables, .exe file, there's no runtime required to run those files.
* Gradle compiling 100,000 lines of Java at ~5,600 lines/s
* Maven compiling 500,000 lines of Java at ~5,100 lines/s
* Mill compiling at ~25,000 lines/s on both the above whole-project benchmarks
Again not to put Java down but have a proper discussion about compiler speeds. I'm not interested in "your" tool is faster than "my" tool, I want to understand compilation speeds of different programming languages and what impacts them. Java and Go have similiar execution speeds + similar simple type systems, no implicits etc, so they should be similar.
Of course beside the obvious, comparing compilation speeds on two totally different CPUs and machines. Do we compare compilers or machines?
Notably, the benchmarks I provide are all single-core. You can get more if you modularize the project and spread out the load over multiple cores, and some of the other pages linked from the OP go into more detail
Pretty impressive numbers, although it’s fair to say here that while Go comes with its own build toolset, pretty much no one uses plain javac to compile stuff. It’s almost always either Gradle or Maven and as the article hints they slow down builds a lot.
> From this study we can see the paradox: the Java compiler is blazing fast, while Java build tools are dreadfully slow. Something that should compile in a fraction of a second using a warm javac takes several seconds (15-16x longer) to compile using Maven or Gradle.
I'd be curious to see what the slowdown is, because my gut feeling is that it simply comes down to QoL stuff tools like maven do. If we keep it to compiling only, stuff like resolving dependencies from the pom.xml and such.
Yes but reality is even worst maven projects take f*"* eternity like the post says, you have tens of atomyse package that make simple task that should take seconds take minutes, while the fast in go is not only the compilation time, but that 28000 is in real word case,at least it'd feels like this for experience.
I was just saying "How fast does Golang compile" because
I'm interested in compilation speeds and CPU usage cross
compilers (Rust, despite it's "slowness" seems to have the best CPU utilization of the compilers I've checked over the years).
I've been using Java from 1996 on for two decades.
A sidenote: The article is hard to read, it's not clear how much IO there is. It seems to use LOC as "all lines" including empty lines and comments, not "of code" (most tools today mean NCLOC when they say LOC). Also not sure why they chose Netty for the test with 500k lines and then only used a sub project with 50k lines.
"Compiling 116,000 lines of Java per second is very fast. That means we should expect a million-line Java codebase to compile in about 9 seconds, on a single thread."
The get the score from compiling 50k of lines without IO it seems and then extrapolate to 1m of lines - does that also fit into memory? No GC? And no IO? At least one would need to check if a file has been changed on disk? Or would the OS do that with a cache check?
"compile your code, build tools add a frankly absurd amount of overhead ranging from ~4x for Mill to 15-16x for Maven and Gradle!"
> These benchmarks were run ad-hoc on my laptop, an M1 10-core Macbook Pro, with OpenJDK Corretto 17.0.6. The numbers would differ on different Java versions, hardware, operating systems, and filesystems. Nevertheless, the overall trend is strong enough that you should be able to reproduce the results despite variations in the benchmarking environment.
> Again, to pick a somewhat easily-reproducible benchmark, we want a decently-sized module that’s relatively standalone within the project
> "typical" Java code should compile at ~100,000 lines/second on a single thread
> We explore the comparison between Gradle vs Mill or Maven vs Mill in more detail on their own dedicated pages
Why? I'm quite curious. There aren't any good benchmarks on the internet, especially ones comparing it to other languages. I'd love to actually see some real numbers showing how far off it is from Java or Go (I don't doubt it is slower than Java or Go, as it is a much more sophisticated language).
My anecdotal evidence suggests it is not as slow as many think. It compiles a 500k LoC (that's count of all code in dependencies) project in ~10s on my M2 Pro.
Don't worry, I wrote this article about Java but my day-to-day work is Scala. We're lucky if we can crack 4,000 lines-per-second-per-core on my pretty vanilla Scala projects x_x
I feel the pain, I've started a startup on Scala (and some years later successfully sold it), but compilation speed and 20 lines type constraint errors where my biggest problems (but I never forget that it enabled us to scale the company and sell it :-) - but if a programming language spawns consulting companies that only help with speeding up compile times, that is a bad sign.
Though when working on a 2M+ LOC Java project 15 years ago, we also spent a lot of money on very fast RAID hard drives in developer machines to speed up compilation. JRebel was a huge relief back then.
reply