> Design for performance thus often comes at the cost of development agility and operational correctness. Being correct and agile yet still meeting performance

> Design for performance thus often comes at the cost of development agility and operational correctness. Being correct and agile yet still meeting performance criteria is a bigger win for most businesses, which usually aren't constrained by cost and raw speed of hardware. This point illustrates exactly the reason why people don't really care about performance. Performance is an arbitrarily deep rabbit hole that you can go down as far as you want. But because performance trades off with other things that people frequently want more (simplicity and maintainability, among others), they stop when performance is "good enough". What is "good enough" for most people? Probably 10x away from what the machine is actually capable of. You probably think I'm being flippant by claiming that these sort of speedups are possible on real applications. I am not. In high performance computing (HPC), this happens surprisingly frequently, perhaps because people are willing to trade off almost anything for performance. Here's an example of a paper showing speedups over some 30 year-old Fortran/MPI code: http://conferences.computer.org/sc/2012/papers/1000a040.pdf http://conferences.computer.org/sc/2012/papers/1000a040.pdf And for this particular application I happen to know that there is another paper in submission which shows additional speedups over what this paper got. People who are willing to squeeze keep finding ways to optimize this application.