Interesting. It looks like Clojure's missing a few obvious optimizations, and is reconstructing the literal structure each time the function is called, or each time the value is used if the literal is directly at point of use.
On the other hand, deref of a global is not exactly blindingly fast either, since it uses Java ThreadLocals under the hood (or equivalent mechanism). Somewhat surprising performance problems when you consider that a literal data structure should actually be right there in the code, constructed already by the Clojure reader at read-time. I guess when class bytecodes are generated it turns into a set of function calls to vec, list, hash-map &c. I suggest at least one of these two alternatives be done: 1. Alter the bytecode generator to turn such literals into a static final field whose initializer generates the structure, plus a reference to that field; if identical literal structures recur the same static final field can be referenced for each copy. 2. Add a defconstant* special form: can be redef'd but is otherwise strictly constant; (binding ...) will not work on it, nor set!. This can therefore be stored and accessed more efficiently, without going through ThreadLocal or anything similar and thread-dependent, for higher speed access and greater JIT potential. Add appropriate defconstant and defconstant- macros to core that wrap the special form and add docstring and metadata support. -- 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
