> Note that the problem is actually the Clojure startup time, *not* the JVM
> startup. JVM starts up in about 0.1sec on my machine. The rest of the time
> is spend loading Clojure code, compiling all the core namespaces etc.
>
>
That's one way to look at it, another is that clojure's design tightly
integrates with the implications of java's tradeoffs. Classloading and
initialization can take a big chunk of time, even on AOT code, and
clojure's decision to map directly to those constructs exacerbates the
problem (though it's worth it for most apps). Any time I make a
command-line launcher, I spend some time writing a shim that uses this code
to defer loading components until necessary:
(defmacro deferred
"Loads and runs a function dynamically to defer loading the namespace.
Usage: \"(deferred clojure.core/+ 1 2 3)\" returns 6. There's no issue
calling require multiple times on an ns."
[fully-qualified-func & args]
(let [func (symbol (name fully-qualified-func))
space (symbol (namespace fully-qualified-func))]
`(do (require '~space)
(let [v# (ns-resolve '~space '~func)]
(v# ~@args)))))
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
