This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (20)
- # boot (5)
- # cider (14)
- # cljs-dev (15)
- # cljsrn (1)
- # clojure (81)
- # clojure-greece (7)
- # clojure-italy (17)
- # clojure-spec (5)
- # clojure-uk (15)
- # clojurescript (143)
- # data-science (1)
- # datomic (7)
- # defnpodcast (4)
- # docs (1)
- # figwheel-main (1)
- # fulcro (37)
- # graphql (1)
- # hoplon (3)
- # luminus (1)
- # reitit (5)
- # shadow-cljs (10)
- # spacemacs (5)
- # tools-deps (14)
- # vim (7)
Looks like a substantial speedup could be had if we just shelled out to the new Graal native image version of the Closure Compiler: https://twitter.com/mfikes/status/1020829541009379328
Here is the details link: https://gist.github.com/mfikes/07be413e34750a9f451bd76d937ff545
I suppose if you warmed up the Java implementation, you could get similar speeds, but most times you apply
:advanced you end up using a dedicated JVM for that, right, and there is no chance to warm up?
:advanced runs as part of the JVM that the CLJS compiler runs in via the Java API so no there is no dedicated JVM used for that.
cljs.core + its dependencies like your example takes
1821 ms on my machine
@thheller What I meant by dedicated in that case is that when you do an
:advanced build, you often run an entire JVM just for that build, and then let that JVM terminate. (You don’t keep it around with its warmed-up optimizations so that subsequent
:advanced builds run faster.)
So on machines like yours,
:advanced builds must not take that long—1821 ms is pretty fast.
@mfikes I frequently run 3
:advanced builds after each other (frontend, backend, admin, etc.) and the JVM is running anyways due to CLJS compilation.
Some initial testing shows that using the Graal version can be slower.
Using it for
script/test (which involves 344 source files), it takes 98 s for the Graal native image, while the in-proc JVM version takes 54 s.
This is consistent with the statement Compilations with a very large number of source files may be slightly slower than the java version. at https://www.npmjs.com/package/google-closure-compiler
If curious, here is how I did the test https://github.com/mfikes/clojurescript/commit/08962d5603628a3fc96740fe63f237068a2914d9
OTOH, repeated looping on that 54 s result in the same JVM lowers it further to about 45 s, so letting HotSpot do its thing is a good thing.
Here is an example of HotSpot showing a speedup with repeated runs
Optimizing 344 sources, elapsed time: 56930.832278 msecs Optimizing 344 sources, elapsed time: 46389.359338 msecs Optimizing 344 sources, elapsed time: 42827.655764 msecs Optimizing 344 sources, elapsed time: 41172.005648 msecs
It appears that Nashorn may not exist long-term (it is deprecated for removal in the JDK 11 codebase): http://hg.openjdk.java.net/jdk/jdk11/rev/fb7800b66c92 If that ever happens, perhaps Graal.JS will be there to take its place. (Speculating.)
Looking at that code, if you run
jjs you may see
Warning: Nashorn engine is planned to be removed from a future JDK release
I’m assuming there is no way to replicate
clojure.spec.alpha/fn-sym in ClojureScript https://github.com/clojure/spec.alpha/blob/master/src/main/clojure/clojure/spec/alpha.clj#L124-L128