A pedant, perhaps, but an important one to me. Performance doesn't matter. Never has, never will. Responsiveness is what matters. Often one must improve performance to get responsiveness, but performance is never important of itself.

For example, if you have some sort of server (whether that be web or otherwise) which can handle 1000 actions per minute, and then you improve the performance to 2000 actions per minute, you've no doubt improved performance. But if there are only 500 actions to perform per minute, then those 500 actions are unlikely to have had a resultant boost in responsiveness. And you've just wasted a bunch of effort. However, if you sometimes have a peak of 1500 actions to perform per minute, then that increase in performance will ultimately mean better responsiveness during that peak.

I don't care that it takes my word processor 1.5 million or 1.5 billion cycles to handle the typing of 5 characters - I have 3 billion cycles per second, the responsiveness of the system won't suffer.

What does that mean to abstraction? Lots. It means that if the system is still responsive when I use more abstraction, then I can save money on programmer time, which will make my system cheaper (theoretically, this would allow the program to be cheaper to produce, either meaning layoffs or more time-enhancing features for the same cost).

You do need to be aware of responsiveness. For example, let's take a database at a bank. It's critical that everyone standing at ATMs, whether your own or your competitors in the same network, can access their cash within a couple of seconds. Most of this time is eaten up by latency, so fast data retrieval is of utmost importance. Yet, the overnight daily summaries given to the executives can take 6 hours to complete and be perfectly responsive.

The biggest difference in my mind between performance and responsiveness is the focus. Performance focuses on code, computing, and programmers. These are always the wrong things to focus on. Responsiveness focuses on customers and users. These are always the right things to focus on. Rather than saying, "I need to get 2000 actions per minute", you need to say, "I need to ensure I can get all 1500 users each minute, at peak volume, their information calculated within 2 seconds of their request." And on the topic of databases, there are tools available to ensure different queries get different priorities to ensure time-critical get more system resources than large reports - I know IBM has their own DB2-branded version, and am guessing that other vendors either have their own, too, or third-parties are providing them. But it's an idea that is focused on the right area: applying the system to the right job at the right time. Focusing on responsiveness, not performance.