@ArtHarg @woe2you @thomasfuchs

Yes, it's more about diminishing returns and closely related to Amdahl's Law.

If I fly to New York, it takes me an hour or so to get to the airport, I then want to allow a couple of hours slack, then it takes a while to go through immigration, customs, and baggage claim, then probably an hour or so to get to my final destination. If the plane takes zero time, it's probably a four hour trip.

Concorde took about three hours, giving a seven-hour total trip time. Current commercial flights take about eight, giving a twelve-hour flight time. Both are basically 'I'm spending the day travelling'. If you live in London and are getting a helicopter from JFK to your office at the far end then Concorde can let you turn up for a lunch meeting and be home at the end. But for most people, this wasn't the case, Concorde was just a much more expensive way of spending the day travelling.

Contrast that with flights vs ships. It takes a week for a (powered) ship to cross the Atlantic. The difference between spending a day each way travelling and spending a week each way is huge. A one-week holiday or a short business trip is feasible with a one-day travelling time. If it takes two weeks for the round-trip travel then most people can't take a holiday.

This also applies to computing things. The laptop I started doing LLVM development on took an hour and a half for a clean build. It took five minutes to link a debug build. With my last laptop, I'd often build on a big server that could do a clean build in 10 minutes and link a debug build in under ten seconds (a lot of that change came from moving to a better linker). My new (well, three years old now) laptop is able to do a clean build in a bit over ten minutes and normally turn around incremental builds in a few seconds. Going faster won't improve my productivity.

And building LLVM is an outlier. Most people don't do batch processing things that are so computationally expensive. 20 years ago, I was doing a bunch of video editing things and the editing tools had a preview and final-version render mode. Preview rendering typically took a minute or two for large segments or tens of seconds for shorter snippets. That really slowed down the working. A few years later, most of these things moved to pixel shaders and later versions of the tools I was using were able to do the preview instantly. Faster than that is not useful.

That's great for consumers, it's less good for an industry that's focused on growth.