ndk.io is a developer's blog about Clojure, JVM startup time, Clojure on Android and CSP concurrency.
HN 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.
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-slow.html
“[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
> 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)
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-times/
[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
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
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/
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