7 ms·

Command-line apps with Clojure and GraalVM: 300x better startup times

118 points by kimi 8y ago

Cthulhu_ 8y ago
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.
- kimi 8y ago
  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+Start+Time https://dev.clojure.org/display/design/Improving+Clojure+Sta... - but GraalVM kills it. It's even worse for serverless!
  - fnordsensei 8y ago
    So, are we saying that really, Graal should be used for Datomic Ions?
- letientai299 8y ago
  I think the startup time in Spring got that long due to resolving graph of dependencies at runtime.
  - jackpeterfletch 8y ago
    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.
    - kimi 8y ago
      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.
  - jacques_chester 8y ago
    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.
- pmarreck 8y ago
  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.
  - lastofus 8y ago
    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 =/
  - pron 8y ago
    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 https://blog.ndk.io/clojure-bootstrapping.html [2]: http://clojure-goes-fast.com/blog/clojures-slow-start/ http://clojure-goes-fast.com/blog/clojures-slow-start/
    - dman 8y ago
      Cant you just have a system clojure process started up and then fork from there?
      - pron 8y ago
        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.
      - pmarreck 8y ago
- exabrial 8y ago
  I've found cdi starts much faster than Spring these days! Glad to see it catching steam
- tikkabhuna 8y ago
  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/ https://www.meetup.com/Londonjavacommunity/events/252118399/ [2] - https://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html https://docs.oracle.com/javase/8/docs/technotes/guides/vm/cl... [3] - http://openjdk.java.net/jeps/310 http://openjdk.java.net/jeps/310
jgh 8y ago
ah this is great. I need to look at switching to Graal.
- exabrial 8y ago
  Graal can be used as the JIT compiler got your JVM. It's also pretty easy to hack on. There a great presentation on YouTube by one of the project leads about that.
Jeaye 8y ago
To the author: https://www.youtube.com/watch?v=OonDPGwAyfQ https://www.youtube.com/watch?v=OonDPGwAyfQ In other words, thank you for the content, but this could really use some proofreading.
- kimi 8y ago
  Guilty as charged :-)
- prudhvis 8y ago
  Thank You. This is a good video to drive the massage.
  - Skunkleton 8y ago
    Nothing like a good massage!
    - ofrzeta 8y ago
      related: "Why is the title of the book The Medium is the Massage and not The Medium is the Message? Actually, the title was a mistake. When the book came back from the typesetter's, it had on the cover 'Massage' as it still does. The title was supposed to have read The Medium is the Message but the typesetter had made an error. When McLuhan saw the typo he exclaimed, 'Leave it alone! It's great, and right on target!' ..." https://en.wikipedia.org/wiki/The_Medium_Is_the_Massage https://en.wikipedia.org/wiki/The_Medium_Is_the_Massage
- pmarreck 8y ago
  wow, that video was amazing! forwarded to some writer/editor friends. thanks!
- kimi 8y ago
  BTW - CLI-matic uses your excellent Orchestra.
  - Jeaye 8y ago
me_again 8y ago
"So you have no excuses not to build your CLI tools in Clojure now." Except that the toy program is 25MB and takes multiple minutes to compile...
- msgilligan 8y ago
  25 MB almost fits on a floppy disk! That's acceptable to avoid dynamic linking or external dependencies. And that 25 MB is a fixed-cost (a JVM-subset, libraries, etc) and as the app adds functionality the fixed 25 MB cost becomes less as a percentage. It's not viable for built-in Linux tools, etc. But for a custom tool where performance matters, it's a great solution.
  - nikanj 8y ago
    A floppy is 1.44MB, so off by more than an order of magnitude
    - msgilligan 8y ago
      I was being a little silly, but there are "floppies" with capacity up to 240 MB: https://en.wikipedia.org/wiki/Floppy_disk#Sizes,_performance_and_capacity https://en.wikipedia.org/wiki/Floppy_disk#Sizes,_performance...
- msgilligan 8y ago
  ... and the multiple minute compile is only for _release_ builds.
- kodablah 8y ago
  That and you are using proprietary Oracle tech.
  - kimi 8y ago
    The CE?
87 8y ago
If you really want to script in Clojure you should probably use Lumo https://github.com/anmonteiro/lumo https://github.com/anmonteiro/lumo . Starts up almost instantly (including a repl!). Still wouldn't recommend. But it's workable.
- kimi 8y ago
  Looked into it, but the big thing of my scripts is that they often use JDBC or http-kit, so cljs would not be as good.
cutler 8y ago
"6G to 8G RAM" to compile. A real win then.
- thomaswue 8y ago
  This compilation step is only required once when you release your tool. The resulting binary is then providing fast startup and low memory footprint whenever users invoke your tool. So, yes, it is a real win if your tool gets used more than once.
  - xfer 8y ago
    Or use like lots of other languages that provide all these "wins" without having to provide justifications like "only for release build and if your tool gets used more than once".
    - yogthos 8y ago
      I spend most of my time actually programming in the language, not compiling it. So, I'm going to optimize for that, but to each his own I suppose.
      - xfer 8y ago
        It's not an either-or, you can have both.
        yogthos 8y ago
        I can't really think of a language that I'd rather use than Clojure right now. So, I'd have to get these "wins" I'd have to switch to working with a language I enjoy less.
codedokode 8y ago
Why cannot Java probuce binaries that can be mapped into memory and shared like native executable files? It could solve the startup time problem. Google even had to invent a zygote process in Android to make apps start faster.
- chrisseaton 8y ago
  > Why cannot Java probuce binaries that can be mapped into memory and shared like native executable files? It could solve the startup time problem. It can. That’s what this article is about.
- fulafel 8y ago
  It can and has been implemented even for OpenJDK, check out http://openjdk.java.net/jeps/295 http://openjdk.java.net/jeps/295

118 points by kimi 8y ago

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.

kimi 8y ago
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+Start+Time https://dev.clojure.org/display/design/Improving+Clojure+Sta... - but GraalVM kills it. It's even worse for serverless!
- fnordsensei 8y ago
  So, are we saying that really, Graal should be used for Datomic Ions?
letientai299 8y ago
I think the startup time in Spring got that long due to resolving graph of dependencies at runtime.
- jackpeterfletch 8y ago
  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.
  - kimi 8y ago
    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.
- jacques_chester 8y ago
  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.
pmarreck 8y ago
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.
- lastofus 8y ago
  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 =/
- pron 8y ago
  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 https://blog.ndk.io/clojure-bootstrapping.html [2]: http://clojure-goes-fast.com/blog/clojures-slow-start/ http://clojure-goes-fast.com/blog/clojures-slow-start/
  - dman 8y ago
    Cant you just have a system clojure process started up and then fork from there?
    - pron 8y ago
      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.
    - pmarreck 8y ago
exabrial 8y ago
I've found cdi starts much faster than Spring these days! Glad to see it catching steam
tikkabhuna 8y ago
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/ https://www.meetup.com/Londonjavacommunity/events/252118399/ [2] - https://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html https://docs.oracle.com/javase/8/docs/technotes/guides/vm/cl... [3] - http://openjdk.java.net/jeps/310 http://openjdk.java.net/jeps/310

jgh 8y ago

ah this is great. I need to look at switching to Graal.

exabrial 8y ago
Graal can be used as the JIT compiler got your JVM. It's also pretty easy to hack on. There a great presentation on YouTube by one of the project leads about that.

Jeaye 8y ago

To the author: https://www.youtube.com/watch?v=OonDPGwAyfQ https://www.youtube.com/watch?v=OonDPGwAyfQ In other words, thank you for the content, but this could really use some proofreading.

kimi 8y ago
Guilty as charged :-)
prudhvis 8y ago
Thank You. This is a good video to drive the massage.
- Skunkleton 8y ago
  Nothing like a good massage!
  - ofrzeta 8y ago
    related: "Why is the title of the book The Medium is the Massage and not The Medium is the Message? Actually, the title was a mistake. When the book came back from the typesetter's, it had on the cover 'Massage' as it still does. The title was supposed to have read The Medium is the Message but the typesetter had made an error. When McLuhan saw the typo he exclaimed, 'Leave it alone! It's great, and right on target!' ..." https://en.wikipedia.org/wiki/The_Medium_Is_the_Massage https://en.wikipedia.org/wiki/The_Medium_Is_the_Massage
pmarreck 8y ago
wow, that video was amazing! forwarded to some writer/editor friends. thanks!
kimi 8y ago
BTW - CLI-matic uses your excellent Orchestra.
- Jeaye 8y ago

me_again 8y ago

"So you have no excuses not to build your CLI tools in Clojure now." Except that the toy program is 25MB and takes multiple minutes to compile...

msgilligan 8y ago
25 MB almost fits on a floppy disk! That's acceptable to avoid dynamic linking or external dependencies. And that 25 MB is a fixed-cost (a JVM-subset, libraries, etc) and as the app adds functionality the fixed 25 MB cost becomes less as a percentage. It's not viable for built-in Linux tools, etc. But for a custom tool where performance matters, it's a great solution.
- nikanj 8y ago
  A floppy is 1.44MB, so off by more than an order of magnitude
  - msgilligan 8y ago
    I was being a little silly, but there are "floppies" with capacity up to 240 MB: https://en.wikipedia.org/wiki/Floppy_disk#Sizes,_performance_and_capacity https://en.wikipedia.org/wiki/Floppy_disk#Sizes,_performance...
msgilligan 8y ago
... and the multiple minute compile is only for _release_ builds.
kodablah 8y ago
That and you are using proprietary Oracle tech.
- kimi 8y ago
  The CE?

87 8y ago

If you really want to script in Clojure you should probably use Lumo https://github.com/anmonteiro/lumo https://github.com/anmonteiro/lumo . Starts up almost instantly (including a repl!). Still wouldn't recommend. But it's workable.

kimi 8y ago
Looked into it, but the big thing of my scripts is that they often use JDBC or http-kit, so cljs would not be as good.

cutler 8y ago

"6G to 8G RAM" to compile. A real win then.

thomaswue 8y ago
This compilation step is only required once when you release your tool. The resulting binary is then providing fast startup and low memory footprint whenever users invoke your tool. So, yes, it is a real win if your tool gets used more than once.
- xfer 8y ago
  Or use like lots of other languages that provide all these "wins" without having to provide justifications like "only for release build and if your tool gets used more than once".
  - yogthos 8y ago
    I spend most of my time actually programming in the language, not compiling it. So, I'm going to optimize for that, but to each his own I suppose.
    - xfer 8y ago
      It's not an either-or, you can have both.
      - yogthos 8y ago
        I can't really think of a language that I'd rather use than Clojure right now. So, I'd have to get these "wins" I'd have to switch to working with a language I enjoy less.

codedokode 8y ago

Why cannot Java probuce binaries that can be mapped into memory and shared like native executable files? It could solve the startup time problem. Google even had to invent a zygote process in Android to make apps start faster.

chrisseaton 8y ago
> Why cannot Java probuce binaries that can be mapped into memory and shared like native executable files? It could solve the startup time problem. It can. That’s what this article is about.
fulafel 8y ago
It can and has been implemented even for OpenJDK, check out http://openjdk.java.net/jeps/295 http://openjdk.java.net/jeps/295