>> If Var reification is part of the slowness of Clojure startup over Java's
It's really not. If you completely removed vars from Clojure on the JVM, Clojure wouldn't be faster by any measurable amount. If someone has benchmarks that say that Vars themselves are the cause of Clojure JVM's slower startup, then I'd love to see those benchmarks, because there's most likely a serious flaw in the measurements. On Thu, Jan 25, 2018 at 9:34 PM, Didier <didi...@gmail.com> wrote: > Really, any comparisons between JS and JVM startup times are not useful at >> all. > > > I'd say its useful to me, if anything because I've learned quite a few > things already from this comparison, and I hope to learn more. > > If Var reification is part of the slowness of Clojure startup over Java's, > and ClojureScript managed without it, yet it delivered 90% of the practical > benefits of Var reification, I could see a potential here maybe. Something > similar to a dynamic or AOT. Flagging some Vars which need not be reified, > or compiling to non reified Vars if fast startup time is what the user > would rather have. I could see this being desirable for use cases like AWS > Lambda, or small scripts, if it had a drastic startup improvement. > > The concurrency issue is interesting, and would definitely be unique to > Clojure over ClojureScript. First time I hear about this being a possible > bottleneck for startup time. Are the concurrency checks java's? Or are > these higher level Clojure concurrency checks? Is there possible > improvement from the Clojure side of them to make them faster? > > @tbc++ seems to imply the apples to oranges are due to the platforms, and > I can accept this to be true, except that I've seen suggestions that the > slow startups are due to either Clojure's implementation causing startup > bottlenecks, or Clojure's core design preventing any kind of fast startup > implementation. Meaning the culprit is Clojure and not the JVM. But as I > find myself thinking about ClojureScript, I wonder if this is true. If > Clojure's core design is the bottleneck, then why doesn't ClojureScript > suffer too? And so, maybe its because it has altered some core design > choices, like concurrency and Var reification. Is it just that? Or is there > also bottleneck in the current Clojure implementation on the JVM, which > were implemented more efficiently on ClojureScript? I know Alex Miller is > working on some of those, and every version of Clojure optimizes, but I've > also heard nothing here is expected to create a game changer improvement > (appart from possibly grouping functions under one class). And if its > neither the implementation, or the core design choices, then I have to > conclude that it is in fact the JVM's fault, in that its core design is > making what Clojure does on startup more expensive then say the V8 design. > Which one of those three things (or possible combination is it) is what I'm > trying to seek answer for here. > > Thanks everyone, > Didier > > On Thursday, 25 January 2018 12:53:03 UTC-8, tbc++ wrote: >> >> Really, any comparisons between JS and JVM startup times are not useful >> at all. For a long list of reasons, not limited to: >> >> * CLJS doesn't have Vars, CLJ does >> * JS VMs are highly tuned for excellent startup times >> * JVM Bytecode is a binary format expressing classes, JS files are text >> files expressing functions and data transformations >> * JVM is class based, JS is prototype based >> * JVM is multithreaded and designed to handle several GB of data, JS VMs >> are single threaded and designed to often deal with less than a GB of data. >> * HotSpot (and most) JVMs are method JITS, JS engines often use many >> profiling methods that are closer to that of a tracing JIT >> * The JVM performs extensive security analysis on loaded bytecode, JS >> engines disallow most security flaws via syntax restrictions >> * CLJS supports tree shaking and minifcation. >> >> All this adds up to an apples-to-oranges comparison. They are completely >> different platforms, the numbers between the two won't be close, and >> drawing any sort of comparison between the two isn't very useful at all. >> >> -- >> >> * No multithreaded safety in vars is not what takes up most of the >> startup time in Clojure. We're talking about single threaded access (var >> initing isn't multithreaded) to a primitive that is updated via a CAS. The >> highest cost you'll see accessing a var in this situation is somewhere in >> the range of a cache miss or two. >> >> >> >> On Thu, Jan 25, 2018 at 1:26 PM, Stephen Nelson <ste...@montoux.com> >> wrote: >> >>> The JVM is concurrent whereas Javascript VMs are singled-threaded. Var >>> initialisation in Clojure uses concurrency primitives to ensure that >>> namespaces are always consistent for all threads, whereas Clojurescript >>> simply assigns to variables. Our profiling of Clojure on the JVM indicates >>> that a lot of the time spent in namespace initialisation is spent in >>> concurrency structures, and this seems much more significant for >>> non-clojure-core namespaces. >>> >>> On Fri, Jan 26, 2018 at 7:22 AM Mikhail Gusarov <dott...@dottedmag.net> >>> wrote: >>> >>>> cljs vars are not reified. >>>> >>>> On Thu, 25 Jan 2018, at 18:24, Didier wrote: >>>> > Based on the profiling performed here >>>> > http://clojure-goes-fast.com/blog/clojures-slow-start/ on 1.9, >>>> > >>>> > It looks like clojure/core__init.load is the slowest bit with load and >>>> > requiring spending the most time on, as well as loadClass, followed by >>>> > clojure/lang/Var.invoke. >>>> > >>>> > Wouldn't ClojureScript also need to initialize all Vars and execute >>>> top >>>> > level forms? You'd think that part would be slower in JavaScript no? >>>> > >>>> > -- >>>> > 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 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. >>>> >>> >>> >>> -- >>> Stephen Nelson | Platform Lead Developer | Montoux >>> e. ste...@montoux.com >>> t. @montoux >>> w. montoux.com >>> >>> -- >>> 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. >>> >> >> >> >> -- >> “One of the main causes of the fall of the Roman Empire was that–lacking >> zero–they had no way to indicate successful termination of their C >> programs.” >> (Robert Firth) >> > -- > 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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.
