Hacker News Reader

Comment by mwcampbell | Hacker News Reader

Why is the startup time so much less for ClojureScript than for JVM-based Clojure? That's quite surprising to me.

Remember that the JVM was originally developed by a company that sold big-iron server hardware; the software on it would typically run for weeks at a time. If you have to make a trade-off during development that sacrifices startup time for overall performance, take a guess as to which one is going to win.

It's not just the JVM, clojure itself takes a while to set itself up http://blog.ndk.io/2014/03/12/clojure-android-startup-benchm...

Android does not have a JVM and Android's Dalvik/ART is not optimized for dynamic languages like the official JVM is. And you won't see this difference when comparing Scala against Scala.js on Android.

At this point you're comparing design choices in Javascript vs Java. Except that I don't buy that the JVM's bytecode is less efficient to interpret than Javascript is. The official JVM actually has a very similar execution model to modern Javascript VMs, with code being first executed in interpreted after which it starts optimizing and compiling the hotspots, with Java's bytecode being optimized to be interpreted first. Android's ART does it differently though, compiling the bytecode ahead of time to native, which is cool for the purposes of Android but misses runtime optimization opportunities for dynamic languages like Clojure.

So no, what actually happens is that normal Clojure insists on loading all namespaces that are used in the program, setting its symbols, vars and functions in the process. Clojure is also a dynamic language and this involves call sites that are not very inline-able and that Android cannot optimize as well as Oracle's JVM can. These problems don't exist with ClojureScript, which in the end is just plain Javascript that also happens to be tree-shaken by the Google Closure compiler.

Didn't realize clojure was dynamic typed when I made my previous comment in the discussion. That explains a lot about performance, ART and java 6 though.

No, it is because Clojure is badly implemented.

Don't blame the JVM for Clojure's quality of implementation.

http://blog.ndk.io/2014/02/11/jvm-slow-startup.html

It's because when we running some Clojure app, it loads a huge amount of classes and creates a tons of their instances. There's a good, but a bit outdated, article about that - http://martinsprogrammingblog.blogspot.de/2012/02/why-is-clo...

And compiled ClojureScript code is just a bunch of js.

I'm surprised that surprises you, JavaScript is heavily optimized for startup and Java has a very long history of being slow to load. How many cli utilities are built on Java/JVM? JVM's speed doesn't show until it has warmed up, that's why it's used for servers.

Sure, I know Sun's JVM is infamous for poor startup performance. But Dalvik is different, isn't it? Not to mention ART, introduced in ANdroid 5.0, where Dex bytecode is AOT-compiled to native code.

Some people do pay for AOT compilation tools for Java. Startup time just like any C coded tool.

http://www.excelsiorjet.com/

If you're referring to the 5× — 7× speed difference for Bocko I included at bottom of the article, I'd be interested in knowing as well. :) Perhaps nvbm (the author) could shed some light. I can only hazard to guess that JavaScriptCore is simply more heavily optimized to reduce startup latency, with this really paying off in the mobile environment.

It's confusing to me that Clojure running on Dalvik can be slower to start than ClojureScript running on Rhino running Dalvik.

I believe nvbm's demo running Bocko on Android using ClojureScript is actually using JavaScriptCore.

Rhino is indeed much slower; that's why Tahmid Sadik is motivated to covert Replicator to use JavaScriptCore over Rhino.

Here is nvbm's article on ClojureScript on Android: https://nvbn.github.io/2015/06/04/livecoding-android/

Not JavaScriptCore, just V8 inside a headless WebView.

I would be a bit skeptical of their load time results without additional info. The numbers are all ambiguous without any details on how they produced them. Another Java 6 alternative on Android is always welcomed, but I'd just like to see them be a bit more verbose on their results. It would also be interesting to see some numbers on the things that really matter in the long run, such as app performance after it loads.

1) What version of Android was tested?

2) Dalvik or ART enabled?

3) Device used and how much memory it had?

4) Reproducible script/steps to how they came up with launch time numbers.

I've heard previously that Clojure had some performance issues compared to other JVM languages like Scala on Android, but I didn't think it could be that much slower to load in comparison. Perhaps Clojure has to load more libraries and thus more overhead.

I guess it's about measurements through my videos, so:

1 - 5.1;

2 - ART;

3 - nexus 5;

4 - I'm measured time with `adb logcat`, it was more accurate than in article, but values are almost the same.

Reply on news.ycombinator.com