Yesterday Apple updated three of their machines. During the announcement, it was revealed that the MacBook Air, the MacBook Pro 13", and the Mac Mini would now be running on M1 SoCs. These "One more thing..." events usually comes with raving numbers and this one did not diverge from the tradition.
If I find the last claim hard to believe[1], Geekbench shows an ARM MacBook Air 2020 putting to shame an Intel MacBook Pro 2019 on a single core basis[2]. It is safe to assume these new laptops provide a large performance increase.
While I am impressed both by the undertaking of replacing an arch and the significant resulting performance leap, there is a caveat.
For a few months, those who will buy M1 machines will enjoy great responsiveness and blazing start-up time. Some once bloated applications will again behave like most tools should. But soon these metrics will start to degrade. Responsiveness and start-up time will progressively revert to what they used to be and old "non-M1" machines will become even slower than they used to.
For every cycle a hardware engineer saves, a software engineer will add two instructions[3].
My most vivid recollection of this issue is from 2008 when I replaced my HDDs with SSDs. It was such a life changer that I wrote about it so the five people who read my blog could also change their lives[4]. Photoshop started within one second. XCode booted instantaneously. It was glorious.
Ten years later, a M.2 NVMe with a Ryzen 5 2600 takes 13 seconds to boot Photoshop. And I no longer use XCode.
It is normal that doing more takes more resources. Modern raytracers require more processing power because they generate better images. Likewise, compilers of 2020 have awesome static code analyzer which they did not have in 2009.
But doing the same thing should never become slower. Starting up an application should never take longer than it used to. If a feature is going to cost start-up time, I would rather not have it.
Is it that we don't care about start-up time? Or is it that we don't have the choice?
Back in 2008, as I witnessed the second Browser War™ where Firefox rose from Netscape ashes to take revenge on Internet Explorer, Google released a new browser.
Firefox had a lot of great features. Among many things, it had tabs, debug tools, and regular bug fixes. Chrome also had these. But when I saw it boot nearly instantly instead of the five seconds it took to Firefox, I immediately switched and never looked back.
As it would later be explained by Google engineers, speed was a core priority.
We carefully monitor startup performance using an automated test that runs for almost every change to the code. This test was created very early in the project, when Google Chrome did almost nothing, and we have always followed a very simple rule:
This test can never get any slower.
Because it's much easier to address performance problems as they are created than fixing them later, we are quick to fix or revert any regressions. As a result, our very large application starts as fast today as the very lightweight application we started out with.
- Brett Wilson, Chrome Software Engineer[5]
Once sluggish, it is hard to get out of the mud to make people look again. Firefox developers famously attempted to fix the five second startup time in 2010 via bug #627591[6]. They fixed many issues but not enough to warrant a second try.
With better hardware like Apple's, creators are mostly left with better tools. Some companies will decline to or won't be able to have "tests that should never get slower" but even this is a good thing. Because to some people, these deficiencies have another name. These are called opportunities.