I think you'll agree with what I'm about to say, but I think it's an important point to reiterate.

You wrote: ...performance is important, and it is always one of the most important measurement of the quality of your application.

In a paper defending the virtues of goto, Knuth wrote about looking forward to the day when computers were fast enough that performance is no longer such a critical concern. Interestingly, his comments relate to yours in two different ways. He was making it clear that performance a necessary consideration but, more importantly, he was directly addressing the "never use goto" dogma that had arisen. (As a third point of relevance, I got that link from the HOP mailing list).

The problem with the dogma was fairly simple: by using "always" as the criteria, one was sometimes forced to go to extreme lengths to avoid goto and this could cause performance issues. In your case, you state that performance is always one of the most important considerations. I tend to disagree.

Admittedly, there are certain classes of problems for which performance issues must be addressed up front. Ray tracing programs are rarely written in Perl. In this case, a better solution that figuring out how to improve the performance of your favorite tool is to figure out the most appropriate tool for the job. C or C++ are going to be big wins here.

If I am forced to pick a "most important" measure of quality, I would argue for program completeness and correctness. In other words, the program should correctly do everything that it is supposed to do and do nothing it's not required to do. Once you have correctness and completeness down then, if performance is still an issue, profiling should be considered.

Sometimes performance is gained by coupling things that shouldn't be coupled, denormalizing the database or writing an obscure algorithm. However, if someone is doing that up front I'm going to be pretty unhappy if they've tripled the speed of a function that only uses two percent of the total program run time. Frequently when programmers guess where the performance problems will be they guess wrong. Thus, by worrying about performance before we worry about correctness and completeness, we're more liable to build overly complicated and confusing code. What's worse, that confusing code is less likely to benefit our overall performance.

Performance is often important, but it should rarely be the first consideration. If we avoid useful (a carefully chosen word) abstractions out of fear they will slow things down, we're hurting our ability to write correct and complete code. Focus on performance after you know the code is right.