[croo]

Huh, so for anyone interested but did not have the time to do the comparison of the two links of OP and parent post:

* java (on a cold jvm): 18.000-32.000 line per second on a single core

* java (on a hot jvm): 102.000-115.000 line per second on a single core

* golang: 28.000 line per second on 12 core

[p2detar]

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.

edit: typos

[creesch]

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.

[KingOfCoders]

Outside a synthetic benchmark:

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

[lihaoyi]

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

[KingOfCoders]

Notably all the benchmarks you provide are synthetic and not achievable by developers. I more care about real benchmarks for real developers, that they can see in their daily working lifes.

[imachine1980_]

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.

[KingOfCoders]

What I love most is how people project.

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

IO? Check for changed files?

[lihaoyi]

All this is actually covered in the article

> 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

[KingOfCoders]

"All this is actually covered in the article"

Then answering none of my questions.

None of your "answers" you quote answers anything to me.

> Again, to pick a somewhat easily-reproducible benchmark, we want a decently-sized module that’s relatively standalone within the project

Why not take netty src? Why is a module more easily reproduceable? We chose a decently sized module because we want a decently sized module does not explain anything.

What about IO? Why lines with comments and empty lines? Or do you even? There is no mentioning in the text as far as I can see, "lines/second" implies this, but then you say "source lines per second", does this include empty lines? I think any compiler can compile a >1.000.000.000/second of empty lines in one file that is already paged into memory.