The Uselessness of "Fast" and "Slow" in Programming

I agree with everything except for the thesis as stated in the title. "Slow" and "fast" aren't useless, but you need to think about and say what you mean.

Software systems are fast and slow because of their slowest component. When we speak there is an implicit understanding of the context, "traversing the list is slow (because it's a hot loop)" or "Python is fast (because I avoid a network request)". We should more frequently make these assumptions explicit. It facilitates conversation and clarifies our thinking.

I had some academic colleagues doing simulation work. Philosophy students with cobbled together Python scripts had advisors tell them to switch to a compiled language as soon as things got slow, or to write a proposal to someone to run it on "the cluster". The issues were algorithmic, of course. Would better terminology have helped them? Maybe.

Is a Ferrari fast? Why hasn't anyone suggested I get a new car when I complain about my commute?

I don't want programmers to stop saying "we can't do that, it's slow" because the software I run is too slow. I want talking about performance to be normal and easy. But maybe the author means we just avoid talking about individual software components as fast or slow. When elements of a series span orders of magnitude the only big one is the biggest, yes, but you don't always know what your components can do when you build them.

I'm responsible for a data processing task that happens once a year. For that, it doesn't matter that some of my requirements are slow, manual processes: ask someone, wait a day. But if we eliminated all of those, the annual update might be a live view. We would never ask for that because everything is already slow.

Sometimes our system is A + B where B is a lot slower than A, but sometimes making A faster anyway enables completely new systems.

I can not think of very many other disciplines that not only span that number of orders of magnitude, but are doing engineering across the entire range. Cosmology may care about quantum mechanics in order to try to determine the behavior of things like neutron stars, but there’s a vast swathe in the middle they don’t cover. Other ideas may leap to your mind, but even 10 orders of magnitude turns out to be really quite a bit! Thinking about things of one size in one moment, then something a billion times bigger or smaller, and caring about both of them and potentially also a range of magnitudes in between, is not common.

Terrific observation. Ecology comes to mind. An individual apex predator might transform a landscape with hundreds of thousands of individuals. A blue whale is like 10^8 times bigger than a plankton.

I think about these very things when I'm at a grocery store waiting to use the payment pad. A super modest CPU these days can do a billion instructions a second, yet it takes a good three seconds or more for the payment pad to get to the point that I can start to use it.

Sure, communications take time, which might explain the amount of time it takes to process my payment. This is to be expected, but what I'm talking about is before I can even interact with the pad.

As someone who runs NetBSD on a 32 MHz m68030 (http://elsie.zia.io - it's compiling stuff right now, so please be patient), I think any system that's newer and faster has no right being less interactive, yet here we are. People often optimize the parts while nobody optimizes the big picture.

have you profiled your web services lately?

Continuously!

There’s a lot of propaganda floating around about how all web requests are bound by DB latency, but I have repeatedly found in my career that this is often not the case

I don't know what "repeatedly" and "often" mean in quantifiable terms, but it's certainly been my consistent experience that measurable latency for HTTP requests is almost always dominated by time spent in I/O waits (syscalls) and not time spent actively burning the CPU.