Perfomance is a word often used with a very narrow meaning.
Other measures of performance people should be more concerned about:
- Programmer's cost vs. output (quality, quantity, speed) vs. happiness (sustainability, burnout) performance (relevant to why we use Perl and not assembly)
- Latency and response (perceived performance very critical in the webapp/GUI world)
- load (running the program once is OK, but 100 times on the same machine? relates to both latency and throughput)
- disk usage (important in some specialized fields, for example high end databases)
- throughput (the "regular" performance, really only worth it when it comes to batch processing *HUGE* amounts of data. why you might want to use assembly and not Perl)
- maintainability, readability, debuggability - think of this as robustness performance - how your app performs in the course of it's entire life, with respect to changing priorities/requirements/staff.
- ...
Performance is not overrated - it's what determines the cost/value ratio of any piece of work. What is overlooked is how you balance the various aspects of performance to maximize effectiveness (cost/value ratio).
Also, wrt throughput, remember that typically when someone runs a long program they tend to run it 10 times before on smaller data, just to make sure it works like they expected. I tend to try to make sure that I can slice that chunk of time by giving nice progress reports, and decent defaults/warnings/hooks, thus usually halving the truly total time, instead of making sure i can fudge data a into data b in the minimum number of opcodes.
Anyway, my point is: Balance is everything.