This article is chockful of things that I've been meaning to talk about.
> Performance is a feature
The software world is full of examples of programs that were dislodged by a faster competitor. Back in the hey-days of bittorrent, µtorrent quickly became the most popular client; git quickly established itself as the most dominant VCS in part thanks to its greater performance on common operations (git branch, git log, git commit) than the competition at the time; ack, silversurfer and ripgrep are the grepping tools of choice nowadays; Chrome's speed compared to Firefox and Internet Explorer made it explode in popularity and it's now the de facto standard for anything web-related.
> Performance changes how users use software
This one is really important. An example, from the list above, is git: with Subversion, I would rarely do branches, because that required a complete copy which could take minutes. Git takes less than a millisecond to create a new branch, and now everybody has switched to a model where any new code is written in a branch to be reviewed and merged when ready.
The tools ripgrep and fd-find (replacements for grep(1) and find(1)) are fast enough that I don't organize my directories very diligently. I put my PDFs in ~/Documents, my code in ~/Code, etc. and I use those tools to find the content I need without having to use a fine-grained directory structure.
> There’s a general observation here: attempts to add performance to a slow system often add complexity, in the form of complex caching, distributed systems, or additional bookkeeping for fine-grained incremental recomputation. These features add complexity and new classes of bugs, and also add overhead and make straight-line performance even worse, further increasing the problem.
This is something that has been bothering me for a while: if a program is slow, it's rare that we look at whether it's making reasonable use of the machine's resources (NB: not optimal use; reasonable use). Instead, we spin up three more EC2 instances, configure a load balancer, add a bunch of shell scripts to split the data, and hope that the new thing is fast enough. It usually isn't and as the article says, it's more complex and more fragile.
> Performance is a feature
The software world is full of examples of programs that were dislodged by a faster competitor. Back in the hey-days of bittorrent, µtorrent quickly became the most popular client; git quickly established itself as the most dominant VCS in part thanks to its greater performance on common operations (git branch, git log, git commit) than the competition at the time; ack, silversurfer and ripgrep are the grepping tools of choice nowadays; Chrome's speed compared to Firefox and Internet Explorer made it explode in popularity and it's now the de facto standard for anything web-related.
> Performance changes how users use software
This one is really important. An example, from the list above, is git: with Subversion, I would rarely do branches, because that required a complete copy which could take minutes. Git takes less than a millisecond to create a new branch, and now everybody has switched to a model where any new code is written in a branch to be reviewed and merged when ready.
The tools ripgrep and fd-find (replacements for grep(1) and find(1)) are fast enough that I don't organize my directories very diligently. I put my PDFs in ~/Documents, my code in ~/Code, etc. and I use those tools to find the content I need without having to use a fine-grained directory structure.
> There’s a general observation here: attempts to add performance to a slow system often add complexity, in the form of complex caching, distributed systems, or additional bookkeeping for fine-grained incremental recomputation. These features add complexity and new classes of bugs, and also add overhead and make straight-line performance even worse, further increasing the problem.
This is something that has been bothering me for a while: if a program is slow, it's rare that we look at whether it's making reasonable use of the machine's resources (NB: not optimal use; reasonable use). Instead, we spin up three more EC2 instances, configure a load balancer, add a bunch of shell scripts to split the data, and hope that the new thing is fast enough. It usually isn't and as the article says, it's more complex and more fragile.