I've read a mot of discussions around that but have never myself looked into the details, so the following may be completely wrong.
My understanding is slightly different: the JVM does not actually load a class before it is first accessed by running code. What takes a long time for the JVM and not for JS engines, I think, is not loading the code, but creating objects. For Clojure to run, all of your functions need to exist as objects in memory. Java bytecode does not have any mechanism to describe objects, so when Clojure starts up, it has to first load the code that defines the classes, then load the code that creates instances of those classes, and then execute that code to actually get the function objects. Only then can it start even thinking about looking at your own code. AOT thus just saves on parsing string files into Clojure lists, but it cannot really help with the problem that all of these objects still have to be created again from scratch at each start up. The javascript engines have a way of representing objects directly (aka json), so this is much less of a problem: a lot of that object creation can be done at compile time and the js engine can just load objects in memory directly from the js file. You can go further (like Lumo does) by preloading these objects in memory directly as part of the executable bundle, skipping the part where you need to parse a string. So in my understanding it mostly boils down to the ability to define objects directly, so they can just be loaded in memory, versus having to load and execute code to create the objects. > On 24 Jan 2018, at 09:09, Didier <[email protected]> wrote: > > So if that is true, then the slow startup times are to blame on Java. I > understand that Clojure does a lot of extra stuff at startup that a plain > Java main method would not, but those extra things Clojure does are slow, > because of the way the JVM handles them, where as they are quite fast on V8 > or other JavaScript engines. > >> On Friday, 14 July 2017 16:24:33 UTC-7, Gary Trakhman wrote: >> My mental model explains most of this away due to the different load >> patterns of java vs v8. In JVM clojure, functions are essentially 1:1 with >> classes, so in a functional language and standard lib, that's a lot of >> classes. Java will eagerly classload your entire app and deps before doing >> any work. V8 takes an upfront hit on parsing into javascript, but the JS >> target fits the structure of clojure itself much more closely. More time >> (not sure how much compared to JVM) will be spent JITing hot code paths, but >> that won't show up in the startup cost. >> >> You can get JVM clojure REPL startup a little faster by AOT compiling all >> your deps, but it's generally not worth it in a development flow. >> >> I think lumo does some extra tricks to keep this upfront cost down that are >> v8-specific: >> https://anmonteiro.com/2016/11/the-fastest-clojure-repl-in-the-world/ >> >>> On Fri, Jul 14, 2017 at 6:20 PM Didier <[email protected]> wrote: >>> This link: >>> https://dev.clojure.org/display/design/Improving+Clojure+Start+Time says >>> that the Java startup time is ~94 ms, while Clojure boot time is ~640 ms. >>> That's a ~680% increase. >>> >>> On my machine the java start time is: ~1042 ms, and the Clojure start time >>> is around ~3108 ms. A ~298% increase. >>> >>> When I time the startup time of lumo against node, I get ~1190 ms for node, >>> and ~1523 ms for lumo. A ~128% increase only. >>> >>> Does Clojure perform more initialization then ClojureScript? And would that >>> explain the much higher overhead Clojure has on top of the JVM, versus >>> ClojureScript? >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to [email protected] >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> [email protected] >>> 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 [email protected]. >>> 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 [email protected] > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > 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 [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
