Clojurians
#cljs-dev
<
2018-07-22
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

mfikes00:07:05

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

mfikes00:07:11

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?

thheller07:07:59

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

thheller07:07:27

just optimizing cljs.core + its dependencies like your example takes 1821 ms on my machine

mfikes11:07:35

@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.)

mfikes11:07:27

So on machines like yours, :advanced builds must not take that long—1821 ms is pretty fast.

thheller13:07:18

@mfikes I frequently run 3 :advanced builds after each other (frontend, backend, admin, etc.) and the JVM is running anyways due to CLJS compilation.

mfikes13:07:10

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

mfikes13:07:43

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.

mfikes13:07:05

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

mfikes14:07:13

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

mfikes14:07:51

Looking at that code, if you run jjs you may see

Warning: Nashorn engine is planned to be removed from a future JDK release

mfikes20:07:17

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

dnolen21:07:26

it could work but not under advanced compilation