5 ms·

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 y

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.

rtpg 11y ago
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-benchmarks.html http://blog.ndk.io/2014/03/12/clojure-android-startup-benchm...
bad_user 11y ago
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.
- yareally 11y ago
  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.
pjmlp 11y ago
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 http://blog.ndk.io/2014/02/11/jvm-slow-startup.html

rtpg 11y ago

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-benchmarks.html http://blog.ndk.io/2014/03/12/clojure-android-startup-benchm...

bad_user 11y ago

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.

yareally 11y ago
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.

pjmlp 11y ago

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 http://blog.ndk.io/2014/02/11/jvm-slow-startup.html