When discussing topics like optimization and performance, there are far too many developers that either believe that performance is not important(!) or that the things taken to optimize the performance of something somehow magically results in making that system less robust.

For the first point, I can not image any developer that has ever uttered the words Damn, this thing is slow regarding their computer or a particular software application running on it, ever thinking that performance is not important. By the fact that you are complaining about somethings performance, that means that performance is important. Or at least, important enough to complain about.

For the second, there are lots of ways to optimize something, and none of them have to directly result in reduced robustness. One of my favorite examples, which is to prefer stack memory over heap memory, can actually improve the robustness of software – it reduces the possible places where exceptions can be raised and thus lessens the chance for exception mis-management to cause problems.

One of the things to remember before opening your mouth to say that performance is not important is to remember that your compiler still optimizes things to the best of its ability. Newer generations of compilers often offer more and better optimization capability as well. Why is this? It is because performance is NOT important, and the compiler writers wanted to just waste time?

When a new processor architecture is made available, manuals that detail that architecture are produced that often specify the best way to utilize that new architecture. Cache utilization, multiple execution engines, out-of-order execution, register allocation, store/load stall scenarios, etc are usually covered in great detail so that all of the capability of that new architecture can be used to its fullest potential.

Again, was that material written just to waste time, or does someone out there know something that you do not – that again, performance is important.

One of the things that today’s developers may often forget is that while their software is running on better hardware, it is also running along with other software applications. For you Windows users, have a quick look at your Task Bar, and SNA area (often mistakenly called the tray). How many applications are you running? Have a look at the process list in Task Manager and see how many processes are really running.

Now compare that value to how many applications you were running simultaneously on previous versions of Windows – 2000, NT, 9x, or even Windows 3.1. As our hardware gets better, we expect to be able to do more with it. But when that many applications are competing for shared resources (CPU, memory, etc.), the specter of performance once again rears its ugly head.

Just like writing device drivers takes a different discipline than writing desktop applications, writing software that has to execute in a shared environment is different than writing software that runs in a dedicated environment. The average desktop developer cannot forget that their software will not be running in an ideal environment, and that just because it works great on the clean demo system, or the developer’s multi-CPU box with 4GB of memory does not mean that its performance is good enough when it hits the target user’s system.