Hacker News Reader

Comment by Cthulhu_ | Hacker News Reader

Generally speaking, startup times for Java / JVM based apps should be worked on next by the teams behind it; in the container age, fast startup is a good thing. I know the JVM itself starts up fast enough, but then going with e.g. Spring on top of that just adds a minute of startup time - and I've no clue what it's doing, I wouldn't think loading config, registering services and opening up a servlet thingy would take so long.

View on HN

Long JVM startup time is a big reason why I went with Elixir instead of Clojure when I decided to move off Ruby to do webdev. (Another reason was easily triggering nasty Java stacktraces.)

My Elixir test suites fire up instantly and finish in seconds (if that) and this fast-as-possible feedback loop is extremely important to stay productive, IMHO.

The editor based REPL is how the Clojure folks stay productive (as opposed to running tests at the command line). Using a keyboard shortcut to eval any expression in your code is really great.

The stacktraces are still often terrible though =/

Clojure startup time is only partly related to JVM startup time, which is ~60ms[1][2]. The reason Clojure startup is slow is because Clojure requires a very elaborate initialization. OTOH, the Erlang VM (BEAM) is much, much, much slower than the JVM (Hotspot, at least).

[1]: https://blog.ndk.io/clojure-bootstrapping.html

[2]: http://clojure-goes-fast.com/blog/clojures-slow-start/

Cant you just have a system clojure process started up and then fork from there?

Forking, in general, is not a very safe operation when the process is an elaborate one, like a JVM. It may, however, be possible to have Graal compile the Substrate VM image for Clojure after the initialization has been done, dumping the initialized state to the image, and then just loading it on launch. This may be the solution chosen once Graal matures a bit, and people learn how to use it well.

Forking is easiest and safest in a functional-data-structure immutable language (where it's basically trivial). Mutable languages? Not so much.

With Clojure you get that feedback loop by running everything in an open repl. No startup time needed.

so you rerun tests in a REPL? what happens when something is redefined?

Typically Clojure apps are structured to be reloadable meaning that you don't have any global state, and you can easily flush the current REPL state http://thinkrelevance.com/blog/2013/06/04/clojure-workflow-r...

There are also tools like lein-test-refresh https://github.com/jakemcc/lein-test-refresh that figure out what needs to be reloaded automatically. You start it up, it watches your namespaces for changes, and reruns tests as needed. As a bonus it can even hook into your OS notification system and let you know if any tests fail.

A lot of editor integration will handle reloading and test-running for you (including VSCode's calva extension, Cursive, and Proto REPL for Atom, although it's less "automatic" than the others).

For Clojure, there is a complex set up of vars in the core namespaces - see e.g. https://dev.clojure.org/display/design/Improving+Clojure+Sta... - but GraalVM kills it. It's even worse for serverless!

So, are we saying that really, Graal should be used for Datomic Ions?

There was an interesting London Java Community meetup[1] this week covering this topic. Matthew Gilliard demonstrated Class Data Sharing[2] and Application Class Data Sharing[3] and its impact on JVM startup times.

My work proxy is making it a pain to find the presentation, I'll try again at home.

[1] - https://www.meetup.com/Londonjavacommunity/events/252118399/

[2] - https://docs.oracle.com/javase/8/docs/technotes/guides/vm/cl...

[3] - http://openjdk.java.net/jeps/310

I've found cdi starts much faster than Spring these days! Glad to see it catching steam

I think the startup time in Spring got that long due to resolving graph of dependencies at runtime.

I remember reading somewhere that Java 9 modules will solve exactly this, as only the required parts of libraries are loaded, and significantly on the used parts of the standard library.

The JVM already does that - it only loads things it needs. So you can have a 2M dependency and only use one static function of a single class in there, and it will only load that - but you have to distribute the whole JAR. With Jigsaw, things are split up, so you can have only the stuff you need.

It's disk I/O. The JVM basically loads classfiles one at a time. When you use Spring Boot, you are asking Spring to pull in potentially thousands of such classes.

Preliminary tinkering by Spring folks shows Graal having a substantial impact there too.

Reply on news.ycombinator.com