We test the performance of Scala.js programs with a large benchmark suite. The benchmarks come from the paper Cross-language compiler benchmarking: Are we fast yet? by S. Marr, B. Daloze, and H. Mössenböck, ported to Scala.
We show here some results from June 2018. More details can be found in Section 4.5 of the Ph.D. thesis Cross-Platform Language Design by S. Doeraene.
In the following graphs, all bars represent execution time (lower is better) normalized against running on the JVM. If a benchmark shows an execution time of 2, it means it executed 2x slower in Scala.js than on the JVM.
In devevelopment mode (fastOpt)
fastOpt configuration is to use the Scala.js optimizer, and keep strict checks for the undefined behaviors of Scala.js.
We can see that, in development mode, Scala.js runs between around 0.9x and 6x slower than the JVM, with the majority of benchmarks in the 1.5x to 3x bracket.
In production mode (fullOpt)
fullOpt configuration, we remove the checks for undefined behaviors.
Moreover, by default we enable the Google Closure Compiler (GCC) in addition to our own optimizer.
In the first set of benchmarks below, we see a general trend. GCC tends to improve the run-time performance a bit, but not nearly as much as our own optimizer. The combination of both is mostly equivalent to just our own optimizer, but the benefits of GCC are mostly about code size.
The only exception is
gcbench, where our own optimizer does nothing on its own, although GCC significantly improves the performance on its own.
The combination of both optimizers still yields the best performance.
In all cases, when both optimizers are enabled, the Scala.js benchmarks run between 0.9x and 3x slower than the JVM.
In the worst case,
In the best case,