N
ndk.io
blog.ndk.io · Personal blog · on HN since 2015
ndk.io is a developer's blog about Clojure, JVM startup time, Clojure on Android and CSP concurrency.
What HN saysHN links it in debates over Clojure and JVM slow startup, where commenters argue the cause is Clojure's initialization. It is also cited for Clojure on Android.
19HN people shared it
13linked it in comments
6stories submitted
218story points
2 years agolast shared
2015people per year2026
Most-shared posts
- 1The (Clojure) "JVM Slow Startup Time" Myth4 people · 2 points · first shared 2016 · 2 comments on HN
- 2Clojure bootstrapping4 people · first shared 2016
- 3Jvm slow startup3 people · first shared 2015
- 4Clojure Compilation: Parenthetical Prose to Bewildering Bytecode (2014)2 people · 153 points · first shared 2016 · 2 comments on HN
- 5The state of Clojure on Android2 people · 55 points · first shared 2015 · 17 comments on HN
- 6Why CSP matters I: Keeping things in sync1 people · 5 points · first shared 2016 · discussion on HN
- 7Why csp matters1 people · 3 points · first shared 2016 · discussion on HN
- 8Jvm vs clojure.svg1 people · first shared 2017
- 9Clojure android startup benchmarks1 people · first shared 2015
- 10Purescript ffi1 people · first shared 2017
What HN people wrote when they linked it
ffreire · 2015-04-29
Were you perhaps talking about this article [0]? If not, it's a good read about the state of Project Skummet and improving Clojure load times on Android.
[0]: http://blog.ndk.io/2015/04/23/state-of-coa.html
outworlder · 2020-09-02
This high startup time in Clojure is a side-effect of the JVM. If you have a hello world program that does nothing it is indeed fast.
If you are running Clojure you need to run at least clojure.core. Loading that is handled - surprise - by the JVM. As would be expected, if you run other implementations (like Dalvik), this can change dramatically (for worse, usually).
So it is correct that loading the JVM itself is not what's taking most of the time. But loading take so much time because of the JVM.
https://blog.ndk.io/clojure-bootstrapping.html
pjmlp · 2019-03-24
Which is a Clojure problem, Java doesn't suffer from it.
https://blog.ndk.io/jvm-slow-startup.html
pron · 2018-07-20
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/
dkersten · 2017-11-03
> Try googling "jvm slow startup".
Its slow because a bare bones hello world takes 40ms in Java instead of 1ms in C. Its "slow" relative to other languages, but its not really that slow over all. I can use mvn without noticing that its slow, but leiningen takes multiple seconds to run a command.
Take a look at this image, taken from the link pjmlp posted: http://blog.ndk.io/img/jvm_vs_clojure.svg
Note that the Clojure team are working on improving this, but it will never be as fast as pure Java and certainly never as fast as other languages (including cljs on node)
niftich · 2017-05-19
The JVM isn't actually slow to start [1] (albeit it does start about 3x-4x slower than python, ruby, or node) [2]. Most of the slow startup in a JVM-based application is in classloading [3] or waiting for your chosen framework to initialize [4] before the control is handed to your custom code.
[1] https://purelyfunctional.tv/article/the-legend-of-long-jvm-startup-tim…
[2] https://dev.clojure.org/display/design/Improving+Clojure+Start+Time
[3] http://blog.ndk.io/clojure-bootstrapping.html
[4] https://jkutner.github.io/2015/12/01/java-boot-time.html
hoodunit · 2017-03-27
Yes, it's fun. I wrote a wrapper for playing Screeps with PureScript and a blog post about it here: http://blog.ndk.io/purescript-ffi.html.
eveningcoffee · 2017-02-01
It is Clojure. It loads an additional runtime by itself. It is unfortunately not usable for CLI applications. Pure Java does the same thing in fraction of time. http://blog.ndk.io/jvm-slow-startup.html
htcw · 2016-02-13
Briefly, the JVM starts very quickly. Most of the time is spent loading the clojure.core namespace. See http://blog.ndk.io/jvm-slow-startup.html
asimjalis · 2016-01-20
Here is the reason for the slow startup time. This is also why AOT compilation does not solve it.
http://martinsprogrammingblog.blogspot.de/2012/02/why-is-clojure-so-sl…
“[It] spends 95% of the startup-time loading the clojure.core namespace (the clojure.lang.RT class in particular) and filling out all the metadata/docstrings etc for the methods. This process stresses the GC quite a bit, some 130k objects are allocated and 90k free-d during multiple invokes of the GC (3-6 times), the building up of meta data is one big source of this massive object churn.”
See also:
http://blog.ndk.io/clojure-bootstrapping.html
provemewrong · 2015-10-07
Yeah, I remember seeing The (Clojure) "JVM Slow Startup Time" Myth [1] in HN comments last week.
[1]: http://blog.ndk.io/2014/02/11/jvm-slow-startup.html
rtpg · 2015-09-30
It's not just the JVM, clojure itself takes a while to set itself up http://blog.ndk.io/2014/03/12/clojure-android-startup-benchmarks.html
sarnowski · 2015-06-22
http://blog.ndk.io/2014/02/11/jvm-slow-startup.html
40ms sounds okay for me, even for most command line tools. Oh and I most probably don't get a segmentation fault ;-)