I can’t understand why people are frightened of new ideas. I’m frightened of the old ones — John Cage

What you find below is a fun exercise in pitching a risky software project to a hypothetical MoneyedCorp’s director-level decision maker. Inspired by musings on software ∩ business by patio11.

Technology tends to progress incrementally with rare leaps. This proposal is for a non-incremental leap in Scala’s 2 compiler performance yielding an estimated 5x-10x speedup. In broad business terms, for a company employing 1000 software engineers this amounts to $1.2 million in savings in gross labour cost per month[1]. Relatively large amount stems from a rare opportunity: Scala compiler is an exceptionally low performer and is a critical bottleneck for a large number of highly paid engineers.

The proposal describes a project of high-risk/high-reward nature.

Why now

Scala compilation performance has been an unsolved problem for more than 6 years — since the time bigger companies adopted the language. Although cumulative gains from small optimizations over the last few years amount to about 2x improvement, bigger savings haven’t been found. Despite no shortage of deeply experienced and talented engineers looking.

Recently, I reached an important milestone in a research project called Kentucky Mule, where I prototyped an alternative architecture of the Scala compiler inspired by Facebook’s Hack. The milestone greatly reduces the technical risk of finding Scala’s language features that make the architecture impossible to implement. The prototype validates the main ideas on a non-trivial code sample: Scala’s standard library.

Before reaching this milestone, the risk of the architecture collapsing in a non-recoverable way was high. There was no practical way to reduce it other than to implement a prototype.

Why nobody has done it before

As informs’ essay elegantly puts it, the innovation builds on the body of knowledge accumulated in incremental steps. The very realization that Scala compiler needs a reworked architecture comes from years of experience working with the current one, optimizing it and encountering its limitations. The thought that there might be a better way is directly inspired by Facebook’s Hack that has been designed to work at a massive scale of Facebook’s code base and with industrial performance expectations. However, Hack’s architecture doesn’t transfer directly to Scala due to Scala’s unique language features.

Secondly, the compilation performance hasn’t been a priority to the original creators of Scala. Scala has academic roots and, sadly, academia doesn’t see compiler performance to be a fruitful research area. As noted by one of the members of the team that worked on the Scala compiler, Scala’s compilation represents “a messy data-dependency problem” with no clear opportunity for an improvement originated in an insight publishable as a paper.

Lastly, the proposed new architecture is non-obvious. Without going into unnecessary details, the problem underlying the new architecture seems to be circular. Breaking the tie requires devising a scheme that seems disconnected from Scala’s core language design. Only careful study and deep understanding of Scala’s specification convinces one that this scheme is workable.

Evidence for the opportunity

A popular argument for Scala’s slow compilation speed is that Scala’s compiler simply has to do more work. The language has sophisticated features and supporting them is computationally expensive. A simple experiment refutes that argument. One can generate an equally basic Scala and Java code side-by-side and compare compilation times between Scala and Java. The difference in compilation speed is 6x in favor of Java. None of the performance analysis work done to date explains that gap.

Another piece of evidence is performance of Kentucky Mule. Kentucky Mule implements a non-trivial subset of Scala’s type checking (the most expensive step in compilation) and performs at 40x the speed of the regular compiler. The logical conclusion is to expand Kentucky Mule’s architecture to regular Scala compiler and hope that performance gap (thus gain) remains large.

Milestones

Duration: 3 months

Deliverable: Kentucky Mule successfully runs on 10 open source projects

Comment

Requires adding support for binary class file parsing and Java types support

Duration: 2 months

Deliverable: Validation of KM architecture’s compatibility with Scala’s As Seen From

Comment

This milestone addresses the central risk in adopting KM’s architecture. One possibility is that As Seen From can be supported but in an expensive way. Being able to test the cost on a real projects will be key in assessing that option.

Duration: 1 month

Deliverable: Validation of KM on MoneyedCorp’s code base

Comment

This milestone ties the work to the code base that’s ultimately validating both feature completeness and performance

Duration: 2 months

Deliverable: Integration of KM into Scala 2 with a dry run mode

Comment

Once this milestone is complete, Kentucky Mule runs as a separate phase in the compiler but its results are not yet consumed by other phases

Duration: 3 months

Deliverable: Broken up the coupling between namer & typer; namer is replaced by KM phase

Comment

Currently, the namer and typer phases are closely coupled together through an intricate web of lazy computations. In fact, the separation is more of a fictional aspiration. The result is known as “big ball of mud”. The tight coupling is one of the reasons why world experts of JVM performance profiling and tuning have a hard time making substantial leaps in improving Scala’s compilation performance.

Duration: 2 months

Deliverable: Profiling and optimization of the type checker

Comment

The new architecture will make the time distribution spent within the type checking phase more apparent and will unlock deep optimizations and scoping of future work