@garyv, I haven't tested/profiled in a really long time, but I recall the majority of startup time being spent in Class.forName. I'm not sure how to verify startup exactly, but it should be easy to profile a top-level repl 'require' call from the user ns, which is doing essentially the same work, except it wouldn't show the difference between direct-linked code and nondirect, and you'd have to be careful to AOT your project so you're not just profiling the compiler.
On Wed, Jan 24, 2018 at 8:39 AM Gary Verhaegen <gary.verhae...@gmail.com> wrote: > 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 <didi...@gmail.com> 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 <did...@gmail.com> 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 clo...@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+u...@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+u...@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. > > -- > 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.
