FYI, you may want to have a look at the following commits:

commit 71930b6b6537a796cdf13c4ffa7cf93eb53b6235
Author: Rich Hickey <richhic...@gmail.com>
Date:   Mon Feb 28 17:55:14 2011 -0500

    improve startup time via lazy defn loading

commit c5681382da775e898915b17f3ab18b49c65359ec
Author: Rich Hickey <richhic...@gmail.com>
Date:   Tue Apr 19 07:41:04 2011 -0400

    temporarily disable lazy fn loading

Cheers,
Michał


On 10 February 2016 at 15:20, Herwig Hochleitner <hhochleit...@gmail.com>
wrote:

> 2016-02-10 13:06 GMT+01:00 Gary Verhaegen <gary.verhae...@gmail.com>:
>
>> Please excuse the very naive question, but if the main problem seems to
>> be compilation of loaded namespaces, what about aot? Does it help at all?
>> If not, why?
>
>
> As far as I understand the problem, it does help a little bit, but much
> less than expected. The main slowdown is not in generating the byte code,
> but in (statically) constructing all the bits and pieces, that constitute a
> namespace: var objects, fn objects, metadata. This is done on every start,
> because JVM lacks any kind of data literals (AFAIK, even arrays are
> constructed piecemeal on the JVM bytecode stack)
>
>
>> As far as I know, the JVM already does lazy loading with Java classes
>> essentially in the way that Mike described.
>
>
> It does, but when require'ing a namespace, every class it comprises is
> loaded, because the vars + their contents must be reconstructed. This is
> where Mike's proposal comes in.
>
>
> BTW Mike: I think your proposal might just work, if we do that kind of
> lazy loading only for vars containing plain fn forms. It would have to be
> done very carefully indeed, since even a metadata expression can have
> side-effects.
> Makes me wonder if that kind of elaborate effect-tracking, couldn't be
> used more generally, to do closed-world tree-shaking on clojure and
> clojurescript in addition to lazyfying side-effect free code-paths, killing
> multiple birds with one stone.
>
> Clojurescript already has GClosure, I hear you say? Right, then why does
> the lower bound for meaningful CLJS programs seem to be at around 600K
> (minified, uncompressed)?
>
> --
> 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.

Reply via email to