3 ms·

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-cloj

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 http://martinsprogrammingblog.blogspot.de/2012/02/why-is-clo... “[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 http://blog.ndk.io/clojure-bootstrapping.html

puredanger 11y ago
Keep in mind the timings in the first blog are 4 years old and the second blog are 2 years old. Both Java and Clojure have made improvements and released new versions.A simple hello world uberjar with the default settings is about 0.775 s for me. Also, Clojure can be AOT compiled with direct-linking and elided metadata which alleviate some of the broader concerns (they're unlikely to affect a hello world type app though). See: http://clojure.org/reference/compilation http://clojure.org/reference/compilation Var class loading is still a concern, so there is of course still room for improvement. Experiments in this area are ongoing. Delayed var loading has the significant downside of making every var call thereafter slower (as the code needs a guard to check whether the class has been loaded or not). invokedynamic shows some promise is getting the best of both worlds there.