> there's virtually no reason you would be exposed to its language implementation choices
Um, doesn't it still have a client that starts up a persistent server and you then have to wait for that server to start up (which, being Java, takes forever) and then deal with those server processes hanging around?
That sounds like being exposed to its language implementation choices.
As opposed to, say, having fast start-up times and not using a server design like basically every other build too.
But my information might be out of date. That's what always soured me on it previously, though.
Bazel doesn't start a server for Java JIT reasons.
It starts a server for (1) concurrency control (2) management of worker processes some languages use (3) caching the build graph (recall that Bazel works with very large code bases).
These reasons are independent of implementation in C++, Go, Rust, Java AOT, etc.
(And yes it doesn't have to use a persistent process to solve these problems. That is the solution it chooses.)
> not using a server design like basically every other build too
Java starts up in ~1s, something like Graal could make this faster. But I find this Java criticism more a symptom of Java-derangement syndrome, because python and node build systems have even worse startup times and no one says anything.
> python and node build systems have even worse startup times and no one says anything.
Noop build with Waf (build system written in Python) takes 0.13s on my system. Waf reports that the build actually takes 0.04s, so I guess 0.09s is Python's start-up time (and some other overhead).
Java Hello World takes 0.132s on my Macbook pro. If I turn on -Xshare:on to use class data sharing, then it drops to 0.119s. Ergo, Java startup time is non-factor. Graal could make this even quicker, for example, a GraalVM AOT helloworld can be reduced to .008s startup, see https://github.com/graalvm/graalvm-demos/tree/master/java-ko... for example.
"time bazel" returns 0.098s
Running a null build took 0.84s, but Bazel does significantly more work, as it's working on a big monorepo, as both a build tool and a package manager.
In short, it is not a problem. But I've had npm take many many seconds for simple operations. "npm list" takes 2.9 seconds.
Python can be slow, depending on the tool. Waf sounds like it is simple and fast, but there are lots of other examples of slow python frameworks out there.
My guess is that startup time is not the issue, but loading a large data structure (its cache) from disk can be.
Especially if you can't or don't want to use memory mapping because it's hard to do well.
But more importantly, I think that the server can monitor file changes ahead of time with things like inotify, saving the time of stat()-ing files when the user wants to perform a build.
Change monitoring with inotify is going to hit limits quickly.
I recently wanted to take a look at VSCode and it immediately shat itself over the maximum number of inotify watches being too low (the kernel I'm running restricts this to 8k for non-root users).
I then bumped the limit to the max (512k, I think, or about 7 copies of linux.git)…still no luck. Now imagine you have a Google-scale number of files.
In-kernal block caching of files is pretty crude - since the kernel has no knowledge of your data structures or which bits of your files you're going to be reading next, you end up having hundreds of page faults requiring single-sector disk reads for most workloads.
That’s often the case if your file format evolves without taking a mmap use case into account. But for a format that’s designed with mmapping in mind, it is often ridiculously faster and more effective.
But most languages and environments don’t let you do that easily.
Aren't the hot compilers kept around under this mechanism to speed up the next incremental build round? I think it's not just caching of intermediate build output but also not letting the tools start from a cold start.
JVM startup for `java -version` is around 150ms on my machine:
$ time java -version
openjdk version "11.0.1" 2018-10-16
OpenJDK Runtime Environment 18.9 (build 11.0.1+13)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.1+13, mixed mode)
real 0m0.159s
user 0m0.116s
sys 0m0.052s
This is how long it takes for a program like git to do actual work. Once you start running an actual program like Maven, it blows up to 500ms for `mvn -version`:
$ time mvn -version > /dev/null
real 0m0.570s
user 0m0.431s
sys 0m0.145s
Bazel takes 150ms to do nothing:
$ time bazel --version > /dev/null
real 0m0.144s
user 0m0.028s
sys 0m0.063s
As a baseline, make takes under 30ms to do nothing:
$ time make -version > /dev/null
real 0m0.025s
user 0m0.002s
sys 0m0.016s
The original comment was "JVM startup is sub-second. Still not great for e.g. small command line utilities, but completely fine otherwise."
For tooling it matters. Some scripts will have backticks and $() and each use of these could be up to a second and be acceptable? Not really. And if you want to run a command like `go fmt` every time you save a file in $EDITOR then you want it to be fast. Maybe when we use the Language Server Protocol everywhere, it will be a different world. But a lot of editors shell out for these features still - and you would never dream of shelling out to e.g. `mvn dependency:tree` because it's too slow.
I think the server is kept around for a number of reasons that have nothing to do with Java startup time. Probably the biggest one is file-watching, using inotify, FSEvents, etc.
Um, doesn't it still have a client that starts up a persistent server and you then have to wait for that server to start up (which, being Java, takes forever) and then deal with those server processes hanging around?
That sounds like being exposed to its language implementation choices.
As opposed to, say, having fast start-up times and not using a server design like basically every other build too.
But my information might be out of date. That's what always soured me on it previously, though.