Jon Pretty

How do you estimate the potential gain of the rare case of a software rewrite that makes sense? You want to differentiate between the two outcomes: - "this is one the best pieces of work I've ever done" - "we tried our best; I wished we knew better from the start"

I went through that exercise when software == compiler. A thread! Let me start off with admitting I'm cheating by narrowing down the gain to performance. Now that we got this out of the way, the answer is reasoning from first principles.

The question is: what's the gap between compiler's performance and the inherent complexity of the problem (e.g. language features) normalized by how quickly computers can compute?

The gap is the estimate of the bloat and excess, use of inefficient algorithms and datastructures in the implementation. I wondered about this for Scala compiler when I was trying to understand whether Scala has a design flaw. So I ran an experiment.

I gasped when I saw this chart for the first time. Dotc is a rewrite of Scala from scratch and it landed exactly at the same performance. For a rewrite of such scale, it's hard to believe no extraterrestrial forces were involved in shaping that chart.

I'm digressing, though. The gap is angular in this chart: you want to compare the relative slopes of the curves for javac and scalac. The comparison shows that scalac/dotc is 6x slower than javac for solving the task of the same complexity.

The lower limit of improving scalac/dotc performance is 6x for this task. I don't know if javac solves the compilation task optimally so this experiment sets just the lower limit.