The people at Triplequote looked at the performance of Scala compilers on different Amazon EC2 instance types in an effort to answer the question, “What is the (cloud) cost per build?”
From the URL:
Q: Scala makes a big deal about how what seem to be language features are implemented as library features. Is there a list of types that are treated specially by the language?
A: The following types are crucial to Scala's type system. They have an influence on how type checking itself is performed.
It’s interesting that you can do some research on this by looking at Definitions.scala.
As a quick note to self, here’s an example of how to set
scalacOptions in an SBT build.sbt file:
scalacOptions ++= Seq( "-Xfatal-warnings", "-deprecation", "-feature", "-unchecked", "-language:implicitConversions", "-language:higherKinds", "-language:existentials", "-language:postfixOps" )
scalacOptions lets you set Scala compiler options in your SBT project build.
If you like reading PDFs of presentations, here’s a PDF from a Twitter employee named How We Built Tools That Scale to Millions of Lines of Code.
scala-lang.org has an article titled Speeding Up Compilation Time with `scalac-profiling` where they demonstrate how they reduced a project’s compilation time from 32.5 seconds down to 4 seconds. In addition to all of the scalac and profiling details, it demonstrates a nice use of flamegraphs.
This typesafe.com chart shows the results of the efforts to make the Scala compiler faster over the last several years.
I haven’t tried it yet, but as a note to self, Scala 2.12.5 introduced a new
-Ybackend-parallelism N compiler flag with which “the backend can now run in parallel on N threads.”
If you ever need definitions of
scalac compiler options (up to Scala 2.12.2), here you go.
As a quick note today, if you’re working on a Scala project and get a compiler error message like this: