2013/3/29 Marko Topolnik <marko.topol...@gmail.com> > Yes, you are involving Clojure startup here, which turns the tables > altogether. This is far more work than just Java startup: all the > namespaces must be initialized: all their def'd values calculated at > runtime and assigned. Some of these may involve quite heavyweight service > startup. This is the real issue in the Clojure startup story: it is not > aggressively optimized towards zero startup time. It is a problem that > carries over to other underlying implementations. >
The opposite is also true and weighs more heavy in this case, I think. Java is not optimized for good startup times. In particular, you can't embed any composite constants in byte code. Not even arrays. That means every last piece of metadata has to be allocated and built from scratch at startup. Every class for every toplevel fn has to be loaded (a process that involves deserialization aswell), initialized and instantiated. In a native code implementation of clojure, all the statically known functions, data and metadata structures could be directly embedded into the binary. Thus the init cost of a namespace with defn as the only toplevel forms could be near zero. -- -- 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.
