4 ms·

The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. But Clojure compiles quite a bit of Clojure code genera

by pron 2y ago

The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. But Clojure compiles quite a bit of Clojure code generating hundreds if not thousands of classes and then loads them before starting up the Clojure program. Still, there's ongoing work on the JVM (Project Leyden [1]) to speed up both startup and warmup even of such programs by caching more state. [1]: E.g. see https://spring.io/blog/2023/10/16/runtime-efficiency-with-spring https://spring.io/blog/2023/10/16/runtime-efficiency-with-sp...

kamaal 2y ago
>>The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. Im yet to reach the X-men level super qualities that can detect, and work in 40 ms chunks. Or at least even notice a 40 ms delays. I envy the humans who can notice such small chunks of time.
- pron 2y ago
  Right, but the problem is that many programs do a lot more work when they start up than Hello, World. The Clojure runtime in particular does quite a lot at startup.
- joshlemer 2y ago
  I don't like how this issue is constantly dismissed out of hand. It very obviously is actually a massive glaring issue which severely limits what clojure can reasonably be used for. Nobody would ever accept a 1 second startup time for CLI applications that we use all the time like git, kubectl, npm, docker, etc.
  - deleted 2y ago
    [deleted]
  - kamaal 2y ago
    npm, docker, kubectl honestly, you are splitting hairs. I plan to run a process for hours, I think 40 ms delays are something I can live with. git- I take more time to write the commit message to worry about 40 ms. I mean sure optimise code to run it fast. But its not something that a human notices.
    - joshlemer 2y ago
      40ms? Clojure Hello World startup time is like 600ms and up. Yes sometimes you run npm and kubectl for hours but most of my usage is just running individual commands that take less than a second.
didibus 2y ago
You still don't see many scripts or CLI apps in Java though. I was wondering if that would change now that you can run a source file directly, but then wouldn't the startup be slower, because now it's also having to compile.
geokon 2y ago
Why can't you do some JVM equivalent of memcopy/execve the starting state of the program? Isn't the initialization procedure (or at least the vast majority of it) exactly the same at each run ?
- pron 2y ago
  That's pretty much the idea behind Project Leyden's "premain" work. The tricky bit is that the program startup being almost exactly the same each time isn't quite the same as being exactly the same. The JVM already caches some things and the capabilities of that mechanism are being expanded to cover more, including JITted code as well as some program computations done at initialisation.
fiddlerwoaroof 2y ago
Back when I wrote Clojure professionally, using GraalVM to generate a native executable of things like clj-kondo basically eliminated the startup latency.
- pron 2y ago
  Right, but Native Image comes with its own tradeoffs. Lyeden's "premain" work aims to be somewhere between the situation today and Native Image.
deleted 2y ago
[deleted]

by pron 2y ago

kamaal 2y ago

>>The JVM cold-starts, loads a Hello, World program from a compressed JAR, runs it and shuts down in 40ms. Im yet to reach the X-men level super qualities that can detect, and work in 40 ms chunks. Or at least even notice a 40 ms delays. I envy the humans who can notice such small chunks of time.

pron 2y ago
Right, but the problem is that many programs do a lot more work when they start up than Hello, World. The Clojure runtime in particular does quite a lot at startup.
joshlemer 2y ago
I don't like how this issue is constantly dismissed out of hand. It very obviously is actually a massive glaring issue which severely limits what clojure can reasonably be used for. Nobody would ever accept a 1 second startup time for CLI applications that we use all the time like git, kubectl, npm, docker, etc.
- deleted 2y ago
  [deleted]
- kamaal 2y ago
  npm, docker, kubectl honestly, you are splitting hairs. I plan to run a process for hours, I think 40 ms delays are something I can live with. git- I take more time to write the commit message to worry about 40 ms. I mean sure optimise code to run it fast. But its not something that a human notices.
  - joshlemer 2y ago
    40ms? Clojure Hello World startup time is like 600ms and up. Yes sometimes you run npm and kubectl for hours but most of my usage is just running individual commands that take less than a second.

didibus 2y ago

You still don't see many scripts or CLI apps in Java though. I was wondering if that would change now that you can run a source file directly, but then wouldn't the startup be slower, because now it's also having to compile.

geokon 2y ago

Why can't you do some JVM equivalent of memcopy/execve the starting state of the program? Isn't the initialization procedure (or at least the vast majority of it) exactly the same at each run ?

pron 2y ago
That's pretty much the idea behind Project Leyden's "premain" work. The tricky bit is that the program startup being almost exactly the same each time isn't quite the same as being exactly the same. The JVM already caches some things and the capabilities of that mechanism are being expanded to cover more, including JITted code as well as some program computations done at initialisation.

fiddlerwoaroof 2y ago

Back when I wrote Clojure professionally, using GraalVM to generate a native executable of things like clj-kondo basically eliminated the startup latency.

pron 2y ago
Right, but Native Image comes with its own tradeoffs. Lyeden's "premain" work aims to be somewhere between the situation today and Native Image.

deleted 2y ago

[deleted]