5 ms·

What step are we talking about? Javac itself is absolutely on the same order of magnitude speed as Go per loc, while rust is significantly slower (which makes s

by kaba0 3y ago

What step are we talking about? Javac itself is absolutely on the same order of magnitude speed as Go per loc, while rust is significantly slower (which makes sense, the latter is a properly optimizing compiler with heavy static analysis, while the former two just spews out java byte code/machine code). Gradle with a daemon is also pretty fast, you are just probably used to some complex project with hundreds of dependencies and compare it to a cargo file with a single dependency.

School-Cotton 3y ago
Just a nitpick, but the static analysis in Rust doesn’t account for most of why compilation is slow, as proven by the fact that cargo check is much faster than cargo build.
- kaba0 3y ago
  Yeah, I know. I believe it’s mostly the amount of LLVM IR that is the problem (e.g. each generic instantiation outputs by default a new copy of roughly the same code), isn’t it?
pkolaczk 3y ago
> Javac itself is absolutely on the same order of magnitude speed as Go per loc Not really when it has to run on a cold JVM. And before it warms up, it’s already done. Then you are in territory of keeping the compiler process between the runs, but that is a memory hog and also not always realiable (gradle often decides to run a fresh daemon for whatever reason). So theoretically, in lab conditions yes, in practice no. > while rust is significantly slower Everybody repeats that but there is surprisingly little evidence in form of benchmarks. I can see rustic compiles over 50k Loc per second on average on my M2, which is roughly the same order of magnitude as Java. And checking without building is faster.
- blackoil 3y ago
  Javac doesn't run in JVM. It is a C (C++?) application.
  - hyperpape 3y ago
    https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/classes/com/sun/tools/javac https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/..., Wiki citation for good measures https://en.wikipedia.org/wiki/Javac https://en.wikipedia.org/wiki/Javac. Maybe you're thinking of Hotspot, which is written in C++.
troupo 3y ago
> Gradle with a daemon is also pretty fast I've yet to see a project where Gradle daemon a) does anything useful and b) is acutally used by gradle itself (instead of seemingly doing everything from scratch, no idea what it does in the seconds it takes for it to start up).
- pkolaczk 3y ago
  This. Gradle wastes tremendous amounts of time on non-compile tasks. So even if Java takes a few seconds to compile, the whole build is often much, much longer. Interestingly, my impression is that maven is significantly more snappy.
- tauchunfall 3y ago
  >I've yet to see a project where Gradle daemon a) does anything useful Also my experience. Only using Gradle deamon does not help making a multi-project setup much faster. You also have to enable build cache, configuration cache and configure on demand with `--configuration-cache --configure-on-demand` and hope nobody in the project breaks the ability for Gradle to use these caches. But then it still took at least 10 seconds to build and start my services (and that's with incremental builds, like you changed one line of code after the first slow build). I spend two days and more after release to speed this stuff up, before it was 30 seconds sometimes 60 seconds. And the protobuf Gradle plugin sometimes did not update the generated code, so you had force-delete the files on every build. And then other stuff in the caches broke and you had to delete `.gradle` directory and sometimes even the `~/.gradle` directory. And sometimes the Gralde daemon hangs so you have to force it to stop with `--stop. Go build, deno and bun are so much more reliable and faster. Something that was surprisingly fast was using the Gradle setup with skaffolding. Java hot code swapping is very fast.

by kaba0 3y ago

School-Cotton 3y ago

Just a nitpick, but the static analysis in Rust doesn’t account for most of why compilation is slow, as proven by the fact that cargo check is much faster than cargo build.

kaba0 3y ago
Yeah, I know. I believe it’s mostly the amount of LLVM IR that is the problem (e.g. each generic instantiation outputs by default a new copy of roughly the same code), isn’t it?

pkolaczk 3y ago

> Javac itself is absolutely on the same order of magnitude speed as Go per loc Not really when it has to run on a cold JVM. And before it warms up, it’s already done. Then you are in territory of keeping the compiler process between the runs, but that is a memory hog and also not always realiable (gradle often decides to run a fresh daemon for whatever reason). So theoretically, in lab conditions yes, in practice no. > while rust is significantly slower Everybody repeats that but there is surprisingly little evidence in form of benchmarks. I can see rustic compiles over 50k Loc per second on average on my M2, which is roughly the same order of magnitude as Java. And checking without building is faster.

blackoil 3y ago
Javac doesn't run in JVM. It is a C (C++?) application.
- hyperpape 3y ago
  https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/share/classes/com/sun/tools/javac https://github.com/openjdk/jdk/tree/master/src/jdk.compiler/..., Wiki citation for good measures https://en.wikipedia.org/wiki/Javac https://en.wikipedia.org/wiki/Javac. Maybe you're thinking of Hotspot, which is written in C++.

troupo 3y ago

> Gradle with a daemon is also pretty fast I've yet to see a project where Gradle daemon a) does anything useful and b) is acutally used by gradle itself (instead of seemingly doing everything from scratch, no idea what it does in the seconds it takes for it to start up).

pkolaczk 3y ago
This. Gradle wastes tremendous amounts of time on non-compile tasks. So even if Java takes a few seconds to compile, the whole build is often much, much longer. Interestingly, my impression is that maven is significantly more snappy.
tauchunfall 3y ago
>I've yet to see a project where Gradle daemon a) does anything useful Also my experience. Only using Gradle deamon does not help making a multi-project setup much faster. You also have to enable build cache, configuration cache and configure on demand with `--configuration-cache --configure-on-demand` and hope nobody in the project breaks the ability for Gradle to use these caches. But then it still took at least 10 seconds to build and start my services (and that's with incremental builds, like you changed one line of code after the first slow build). I spend two days and more after release to speed this stuff up, before it was 30 seconds sometimes 60 seconds. And the protobuf Gradle plugin sometimes did not update the generated code, so you had force-delete the files on every build. And then other stuff in the caches broke and you had to delete `.gradle` directory and sometimes even the `~/.gradle` directory. And sometimes the Gralde daemon hangs so you have to force it to stop with `--stop. Go build, deno and bun are so much more reliable and faster. Something that was surprisingly fast was using the Gradle setup with skaffolding. Java hot code swapping is very fast.