Lazy var loading is one of the things we're looking at. There is some work on this early in the "direct" branch (although at this point it's pretty out of sync with current code).
On Wednesday, February 10, 2016 at 2:22:12 AM UTC-6, Mikera wrote: > > Good initiative, I've filled in a response to the survey. > > One thing that strikes me is that the main issue with loading time is the > time required to transitively load and compile all the referred namespaces > (which can be a lot in a big project...). This in turn may trigger class > loading of Java libraries, IO as various resources are initialised etc. An > observation is that a lot of this is often not required initially, so there > *might* be a clever strategy to mitigate this through laziness. > > This could be something like: > - When loading the current namespace, *don't* load referred namespaces > (yet) > - Create lazy placeholders within vars in the current namespace for (for > every def, defn etc.) > - Only when the placeholder is deref'd / invoked then compile the relevant > function and pull in dependencies. > - After first deref / invocation, replace the placeholder with the full > compiled function / value, so that subsequent access has no overhead > > This would be a pretty big change, and might break tools that make > assumptions about order of loading of namespaces... but I think it would > solve 90% of the boot time problems if implemented correctly. > > The other potentially big win would be concurrent loading of namespaces. > Guess you are looking at that already? > > > > On Wednesday, 10 February 2016 02:36:43 UTC+8, Alex Miller wrote: >> >> I'm doing some research on slow Clojure boot time and would be interested >> in collecting info about example use cases where it's been a problem for >> people. >> >> http://goo.gl/forms/eSpn8M5FNB >> >> I'm not expecting to release the results in any formal way, mostly >> looking to use it to pull out particular use cases and/or commonalities >> across anecdotes so that we can work on boot time problems that matter the >> most (and solutions likely to help the most). Any numbers you can provide >> would be great. >> >> Alex >> >> >> -- 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.
