I'm currently using the fastload branch against alpha5, and it's pretty good. You have to be careful though with namespace declarations as you may end up loading more than you need to. I'm currently in the process of breaking my app down into "runlevels", where it loads the minimum needed to get started and then once that's all done and the app is responsive it starts loading the namespaces that might not be needed for a little while. I got a large chunk of my start up time back by avoiding loading all of tools.analyser for core.async (see my blog post on the subject here <http://adamclements.github.io/articles/core-async-runtime-dependencies/>).
I think by doing this and being careful what you load (my build of clojure has logging turned on for when it loads/compiles individual namespaces and how long it takes repo here <https://github.com/AdamClements/clojure>), it should be possible to get something up and running pretty quickly. On Wed Jan 28 2015 at 16:34:52 Ashton Kemerling <ashtonkemerl...@gmail.com> wrote: > A lot of the slowness in Clojure comes down to how slow it is to load the > main namespaces that are needed, especially clojure.core (see this post > <http://nicholaskariniemi.github.io/2014/02/25/clojure-bootstrapping.html> > ). > > You should also look into the Clojure fastload branch, which apparently > helped out a few Android programmers according to the clojure-android > google list. > > On Friday, November 21, 2014 at 2:48:20 PM UTC-7, Alan Moore wrote: >> >> >> On Friday, November 21, 2014 9:50:58 AM UTC-8, Uday Verma wrote: >>> >>> Hello Everyone, >>> >>> Basically the approach is this: cljs -> js -> rhino [3] -> bytecode. >>> Provides java interop through rhino. By the time things get to rhino, >>> google closure has already thrown away most of the runtime away since we >>> didn't use it, and we end up with manageable amount of JS which is compiled >>> to manageable amount of byte code. All of jvm is still available. >>> >> >> Sounds like the clojure compiler could benefit from dead code >> elimination. I'm not sure if that is possible or not but it does sound like >> it might work. Compiles would probably take longer so the gains might be >> offset by longer compile times. If this is the case then it wouldn't help >> development workflows but could provide deployment/runtime gains. >> >> I'm wondering if the availability of eval in clojure and the lack of it >> in clojurescript makes a difference - it might lead to some code that can't >> be properly analyzed. >> >> Alan >> >> -- > 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/d/optout. > -- 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/d/optout.
