On Mon, Dec 14, 2009 at 07:26, mac <markus.gustavs...@gmail.com> wrote: > On Dec 13, 11:44 pm, dysinger <t...@dysinger.net> wrote: >> So in my experiments with using clojure / contrib w/ the "new" branch, >> I've noticed a pattern of binary incompatibility. Jars pushed to >> clojars, maven repos and other places that are are unnecessarily >> AOTed, don't work with clojure "new". I noticed the same thing going >> from clojure 1.0 to clojure 1.1.0-SNAP. >> >> It doesn't really seem to matter if you include the src "clj" files >> along with the class files in your jar. As soon as clojure hits a >> classfile with an older AOTed namespace, it blows up. This isn't a >> criticism of clojure. Clojure needs it's freedom to innovate. >> >> ...but clojure, by default, JIT compile clj files. I would just like >> to start a conversation about using AOT sparingly if you publish your >> clojure project as a library. Ask yourself "why am I AOTing this >> namespace? Do I think JIT compiled dynamic clojure is dumb? Is this a >> gen-class I need outside clojure in some fancy XML config file? Is >> there some classloader issue that makes it necessary to compile AOT ?" >> If the answer is NO, then please don't AOT the code. >> >> I went through the pain of 3 days of on/off twiddling with libraries >> so our project could use clojure "new". The hair-pulling details >> where in all the code that was AOT when there was no reason to do >> this. 99% of time there were no gen-class or anything else to require >> it. People just like compiling stuff [ I get the feeling they think it >> has some sort of ricer benefit to AOT compile ]. Most clj files work >> great with all versions of clojure if you just jar the clj files and >> leave class generation for runtime. >> >> Don't get me wrong, there are places where a single namespace or two >> are necessarily AOTed for interop or for classloader issues. But just >> carte blanche AOT makes it harder on other people using your library - >> to the point of trying to remove your library from their dependencies >> (trust me - been there). >> >> Code that _could_ run perfectly on clojure 1.0, 1.1.0-SNAP and "new" >> are restricted to one version when AOTed and 99% for no reason. >> >> Maybe Rich can comment on where I am missing it. But I think this is >> my stance. >> >> -Tim > > I've never really used many clojure libs at the same time or even any > very big ones so maybe I'm mistaken here, but does not AOT compilation > help startup time?
Yes, it does help considerably with startup time. I got into the habit of AOT compiling my stuff because my primary development machine has a 1.6GHz Atom and starting up from "slim" builds was too slow for my taste. That said, I think Tim's point is well taken. I should back away from AOT compiling again and see if the performance is still as much of a problem as I remember. This issue has also been brought up in connection with leiningen, which currently AOT-compiles everything as part of its normal build. My impression is that it would be smarter to be selective about what gets AOT compiled, and what doesn't. // Ben > I know everyone is all internetty and webby these days but I kinda > like desktop apps myself and those need to start and stop a lot more > than server apps, which makes such things important. > Also from a developer point of view working with server software it's > nice if you can restart things quickly when the system has gotten into > a bad state because you carelessly deployed something broken on your > dev machine. > > But if the time difference is not noticeable, then I certainly agree > with you for open source projects. > > /Mac -- 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
