There has always been a mini religious war between programmers about code layout/style and when to optimize. My personal take on this has been put more weight on readability and maintainability over highly condensed, optimized code. Here's a few thoughts on this subject:
Don't optimize first
In almost all cases I have ever seen, optimizing while writing your first beta of code leads to poor readability and few gains. There are a variety of load testing suites available out there, what I recommend is to hold off on optimization until the majority of the application is complete. Then design some intelligent load tests and figure out where your bottlenecks are. In most cases I have seen, the majority of "slow code" can be tracked down to a few trigger points, generally less than 5% of the code.
On the other hand, if you optimize first, you end up with code that is harder to read and maintain in places where the performance benefit simply isn't worth it.
Trust your compiler
Most modern languages like .NET have compilers that optimize your code for you. A common mistake I see coders making is that they write poorly readable code in an attempt to optimize things that the compiler would have taken care of anyway. It is very important that you understand how your compiler works! DO NOT waste your time optimizing a block of code until you compile it and peek at the compiled code (.NET Reflector rocks for this). Oftentimes you'll find that the IL language does exactly what you would have done in a re-write. It would be a shame to change some readable easy code to illegible optimized code and get a 0% increase in performance.
A Few Tips
- In most business applications the slowest thing you do is access the file structure and the database. With this in mind make use of caching and if you are going to access the database, try to get as much data as you think you'll need in one shot instead of making x number of calls in a single procedure.
- The balancing statement for the above is that you should avoid loading data you don't need!
- If a section of code with database logic is exceptionally slow, check the database first. Many times it's just a simple thing such as not having an index.
- Organize your Switch/Case statements logically. This means putting your most common occurances near the top of the statement so that less evaluations will occur on average before finding the correct case.