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?

@mfikes closure :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.

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

it could work but not under advanced compilation