On Wednesday, January 24, 2018 at 9:10:34 AM UTC-6, Gary Trakhman wrote: > > @garyv, I haven't tested/profiled in a really long time, but I recall the > majority of startup time being spent in Class.forName. >
There was a bug (CLJ-1529) related to excessive use of Class.forName() in the compiler (particularly visible in macro-heavy code) but that was fixed in Clojure 1.7. Very approximately in the same ballpark CLJ-2210 was fixed in Clojure 1.9. I doubt that you would see this a hotspot on this today (beyond the fact that loading a lot of code loads a lot of classes). > 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. >> > Loading AOT'ed Clojure code will require loading the classes and initializing each var in the loaded namespaces. Loading non-AOT'ed Clojure code requires first reading and compiling the code, and also loading the classes and initializing vars. Of all of these steps, loading classes is generally the fastest - Java has spent a lot of time optimizing the load of classes from jars (and there's even more we could potentially take advantage of). When I have profiled it, reading and compiling usually end up being about the same order of magnitude. Var initialization varies a lot (you could be doing anything in there), but certainly having work to do for every var has a cost that adds up, particularly if you load 100s of namespaces on startup (which is not uncommon in web apps). > >> 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.
