6 ms·

Java build times are very fast. You are just measuring your internet speed here. (Also, gradle is faster as a build tool for incremental compilation)

by kaba0 3y ago

occams_chainsaw 3y ago
...very relative
pkolaczk 3y ago
Gradle is faster than what? Than maven? Maybe. But not than Go or Cargo.
- wokwokwok 3y ago
  Itself. > gradle is faster as a build tool for incremental compilation Implicit: > …than it is building from scratch, where it needs to download lots of stuff I mean, yes, saying Java builds are fast does seem a bit “rolls eyes, yes technically by loc when the compiler is actually running” …but, ^_^! let’s not start banging on about how great cargo/rust compile times are… they’re really terrible once procedural macros are used, or sys dependencies invoke some heinous c dependency build like autoconf and lots of crates do… and there’s still a subpar incremental compilation story. So, you know. Eh. Live and let live. Gradle isn’t that bad.
  - pkolaczk 3y ago
    So maybe I was just unlucky with gradle and lucky with cargo. A project that is a mixture of 20k LoC Scala and 300k LoC Java took 6 minutes to compile, and incremental was still several tens of seconds. Cargo/Rust cold compiles a project of 1M LoC (all dependencies) in about 1:30 on the same hardware and incremental is like 2-4 seconds. As for precedural macros - yes they can be slow to compile but so are Java annotation processors.
    - kaba0 3y ago
      Scala is a much different case, it has one of the most advanced type systems, many implicit scoping rules etc. Even a java change that might affect the scala codebase could result in a slow incremental build. Also, the build system may not have been as modular as it could. In my experience, java annotations gets processed very fast.
      - pkolaczk 3y ago
        > it has one of the most advanced type systems Well, that's a bit of a stretch. It is definitely one of the most complex type systems due to interactions between nominal sub-typing and type classes which is a bit hairy. But in terms of what this type system can express or prove, it's both inferior (cannot express lifetimes or exclusive access) and superior (HKTs, path dependent types) to Rust in some aspects. Let's say they are close.
        kaba0 3y ago
        > It is definitely one of the most complex type systems due to interactions between nominal sub-typing and type classes That’s what I meant mostly. Though if I’m being honest, I’m not familiar with the implementation of either language’s type system.
    - lenkite 3y ago
      Scala is the problem here. Scala has several issues filed for slow compilation. 300K LOC Java should be done within ~1.5 minutes flat from zero. Can be even faster if you are running maven daemon for example. Or even within ~30 seconds if everything is within one module and javac is only invoked once.
- wiseowise 3y ago
  That depends on project and scope of the project.
- 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.
- troupo 3y ago
  I don't even think it's faster than Maven.
sixlelyt321 3y ago
But run time is slow, is that you want to convey?
- kaba0 3y ago
  No, I would even go as far as to say that a naive, non-microbenchmark java program can often perform better than a naive, low-level language one.
troupo 3y ago
Gradle and fast should not be in the same sentence. I have no idea what gradle and its daemon do except spending orders of magnitude more time starting up than running the actual build. You're much better off running javac directly. Then it's fast.
- kaba0 3y ago
  Then someone in your team failed learning the bare minimum to write a sane gradle file, and are putting imperative stuff into the configuration phase. For big projects, compiling only what’s necessary is a huge time win.
  - troupo 3y ago
    > Then someone in your team failed learning the bare minimum to write a sane gradle file Then someone in over 15 years and 8 versions gradle failed to make a system that doesn't require "learning to write sane gradle files" to make sure that it's only two orders of magnitude and not five orders of magnitude slower than it can be. > and are putting imperative stuff into the configuration phase Has nothing to do with the slowness that is gradle. > For big projects, compiling only what’s necessary is a huge time win. It is, and no one is arguing with that
    - kaba0 3y ago
      It is your own failure if you beat the tool over yourself, for not having learnt it.
      - troupo 3y ago
        A tool that: - in 15 years is still slow by default - in 15 years could not acquire any sensible defaults that shouldn't need extra work to configure - is written in an esoteric language with next to zero tools to debug and introspect - randomly changes and moves thing around every couple of years for no discernible reason and making zero impact on reducing its slowness - has no configuration specification to speak of because the config is written in that same esoteric programming language And its zealots blame its failures on its users

Java build times are very fast. You are just measuring your internet speed here. (Also, gradle is faster as a build tool for incremental compilation)

by kaba0 3y ago

Java build times are very fast. You are just measuring your internet speed here. (Also, gradle is faster as a build tool for incremental compilation)

occams_chainsaw 3y ago

...very relative

pkolaczk 3y ago

Gradle is faster than what? Than maven? Maybe. But not than Go or Cargo.

wokwokwok 3y ago
Itself. > gradle is faster as a build tool for incremental compilation Implicit: > …than it is building from scratch, where it needs to download lots of stuff I mean, yes, saying Java builds are fast does seem a bit “rolls eyes, yes technically by loc when the compiler is actually running” …but, ^_^! let’s not start banging on about how great cargo/rust compile times are… they’re really terrible once procedural macros are used, or sys dependencies invoke some heinous c dependency build like autoconf and lots of crates do… and there’s still a subpar incremental compilation story. So, you know. Eh. Live and let live. Gradle isn’t that bad.
- pkolaczk 3y ago
  So maybe I was just unlucky with gradle and lucky with cargo. A project that is a mixture of 20k LoC Scala and 300k LoC Java took 6 minutes to compile, and incremental was still several tens of seconds. Cargo/Rust cold compiles a project of 1M LoC (all dependencies) in about 1:30 on the same hardware and incremental is like 2-4 seconds. As for precedural macros - yes they can be slow to compile but so are Java annotation processors.
  - kaba0 3y ago
    Scala is a much different case, it has one of the most advanced type systems, many implicit scoping rules etc. Even a java change that might affect the scala codebase could result in a slow incremental build. Also, the build system may not have been as modular as it could. In my experience, java annotations gets processed very fast.
    - pkolaczk 3y ago
      > it has one of the most advanced type systems Well, that's a bit of a stretch. It is definitely one of the most complex type systems due to interactions between nominal sub-typing and type classes which is a bit hairy. But in terms of what this type system can express or prove, it's both inferior (cannot express lifetimes or exclusive access) and superior (HKTs, path dependent types) to Rust in some aspects. Let's say they are close.
      - kaba0 3y ago
        > It is definitely one of the most complex type systems due to interactions between nominal sub-typing and type classes That’s what I meant mostly. Though if I’m being honest, I’m not familiar with the implementation of either language’s type system.
  - lenkite 3y ago
    Scala is the problem here. Scala has several issues filed for slow compilation. 300K LOC Java should be done within ~1.5 minutes flat from zero. Can be even faster if you are running maven daemon for example. Or even within ~30 seconds if everything is within one module and javac is only invoked once.
wiseowise 3y ago
That depends on project and scope of the project.
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.
troupo 3y ago
I don't even think it's faster than Maven.

sixlelyt321 3y ago

But run time is slow, is that you want to convey?

kaba0 3y ago
No, I would even go as far as to say that a naive, non-microbenchmark java program can often perform better than a naive, low-level language one.

troupo 3y ago

Gradle and fast should not be in the same sentence. I have no idea what gradle and its daemon do except spending orders of magnitude more time starting up than running the actual build. You're much better off running javac directly. Then it's fast.

kaba0 3y ago
Then someone in your team failed learning the bare minimum to write a sane gradle file, and are putting imperative stuff into the configuration phase. For big projects, compiling only what’s necessary is a huge time win.
- troupo 3y ago
  > Then someone in your team failed learning the bare minimum to write a sane gradle file Then someone in over 15 years and 8 versions gradle failed to make a system that doesn't require "learning to write sane gradle files" to make sure that it's only two orders of magnitude and not five orders of magnitude slower than it can be. > and are putting imperative stuff into the configuration phase Has nothing to do with the slowness that is gradle. > For big projects, compiling only what’s necessary is a huge time win. It is, and no one is arguing with that
  - kaba0 3y ago
    It is your own failure if you beat the tool over yourself, for not having learnt it.
    - troupo 3y ago
      A tool that: - in 15 years is still slow by default - in 15 years could not acquire any sensible defaults that shouldn't need extra work to configure - is written in an esoteric language with next to zero tools to debug and introspect - randomly changes and moves thing around every couple of years for no discernible reason and making zero impact on reducing its slowness - has no configuration specification to speak of because the config is written in that same esoteric programming language And its zealots blame its failures on its users