On Friday, March 29, 2013 5:37:19 PM UTC+1, Herwig Hochleitner wrote: > > 2013/3/29 Marko Topolnik <marko.t...@gmail.com <javascript:>> > >> 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. >
An excellent point. Indeed, the semantics of the JVM are not specfiically geared towards quick startup. Do mind, however, that this is just specification we're talking about. An implementation may perform any optimization as long as it maintains the semantics. As an obvious example, take the startup of the JVM itself, which loads and initializes many hundreds of classes, and sets up a myriad of internal datastructures, within 100-200 ms. This kind of optimization is unfortunately not something client code can participate in, and that's where many problems start. Clojure would basically need its own custom JVM derivation which would provide an accessible way to "fossilize" a namespace and turn it into a binary blob that can be loaded in microsecoonds, resulting in a fully initialized image in memory. At a certain point in this departure from the JVM comes a moment where it is saner to start from scratch and build your own runtime, but that means you undo some 15 years of experience in building and optimizing a runtime for heayweight production systems. Some lessons can be carried over, but a huge spectrum of fine detials will be left for you to reinvent. As long as the JVM is alive and strong I doubt we shall ever see a native implementation that wouldn't cause frustration to its users, because it won't be the universally best choice. For many years to come nothing will be able to dethrone the JVM at the server side, where startup time means nothing and long-running stability is precious. So whatever runtime you choose, it will take you only that far before its specific limitations start giving you a headache. But hey, that's life: no language has conquered all the bases. Otherwise C would by now be just a tale from the elders. -marko -- -- 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.
