This is great, huge thumbs up to all the people involved in this effort. We use ClojureScript on the web and we love every second of it, I'm sure the experience on Android will be the same, especially with the reduced startup time.
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.
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.
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.
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.
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.
