Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

2018-02-01 3:24 GMT+01:00 scott stackelhouse : > CRIU seems like it could actually help in this case. In particular, > paired with Docker, I can just restart from a known good checkpoint with > editor loaded, repl up and connected, etc. That would be very nice. >

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

I was just reading about Docker+CRIU. For me, the slow startup isn't much of a bother for normal operations of my apps. They are generally long running services. But development is where I am bothered by it the most. It can be painful to restart a repl and it's very disruptive to my

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

With the help of criu [1], I can get clojure's startup time on jdk 1.8 down to around 300 - 350 ms [2] This could be considered cheating, because it only works on linux with `CONFIG_CHECKPOINT_RESTORE=y`, but it also demonstrates, what can be achieved with kernel support. [1] https://criu.org/

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

In Lumo case there is heavy optimisation of startup time in not loading CLJS from JS sources at all. They use V8 Startup Snapshots. See https://anmonteiro.com/2016/11/the-fastest-clojure-repl-in-the-world/ for more details. Dne sobota 15. července 2017 0:20:28 UTC+2 Didier napsal(a): > > This

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

Also what I was referencing in terms of the CAS was deferring submission until the namespace is fully initialised. Something akin to a SQL transaction where it could use mutable state and then transform it to the immutable map at commit (eg end of the file). Until a ns fully parsed and processed

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

Hi Alex, That’s cool! I was looking to explore alternatives optimisations to what you had already outlined and which I could potentially do with little effort. I started writing something to do parallel loads back in Sept/Oct. and was replicating some of what Buck/Blaze/Basel do in terms of a

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

On Friday, January 26, 2018 at 12:39:06 PM UTC-6, Justin Smith wrote: > > a nitpick on point 1 - I would assume you can't expect hotspot to improve > anything in the timescale of a program startup > hard to say there are a lot of lock optimizations. I'm not well-versed enough in that stuff

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

a nitpick on point 1 - I would assume you can't expect hotspot to improve anything in the timescale of a program startup am I missing something here? On Fri, Jan 26, 2018 at 10:32 AM Alex Miller wrote: > With a few custom patches (which are pending in jira) + AOT + direct

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

With a few custom patches (which are pending in jira) + AOT + direct linking + lazy vars + var meta elision + jvm flags, I have gotten raw startup as low as ~450 ms. Past that, radical changes are probably required which are unlikely to be worth doing. On your conclusions: 1. minimize CAS'es

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

It's not a huge contributor but Class loading isn't free and Clojure could optimise it in a couple of places. I think with a couple of months effort in optimisation you might be able to get it down to 500ms for a simple "hello world". I'm doubtful you can get it much lower than that. TBH I'm not

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

I would suggest everyone here read this document: https://dev.clojure.org/display/design/Improving+Clojure+Start+Time It goes into a lot of detail on prior work in this area, and I'd say the benchmarks on it should be quite informative. But let me also go into a bit more detail into how CLJS

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

>> 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

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

> > 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

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

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

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

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

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

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

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

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

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

@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,

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

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

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

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

Re: If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

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

If Clojure is to blame for the majority of the startup time, why doesn't ClojureScript proportionally slow down the JavaScript startup time also?

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%