Anyone who reads a lot of SO questions knows that the need to preach against premature optimization is not going away anytime soon - but what about the other extreme, the projects that fail or struggle because they did not consider performance early enough?
Should you just try and get a working system as quickly as possible so you can do performance tests, or are there some optimizations so essential that they should always be considered right from the beginning?
Loop optimizations should always be made early. That is when the algorithm is most clear in your mind.
It may be best to view this in the light of things you should avoid, because they are universal performance-killers, and which are hard to change once implemented, because they become part of the application design.
Off the top of the head I can think of:
We build the code, and if performance is an issue, we fix it using the apropriate tools.
The big problem with optimized code is that it is often more complex. And complex code is hard to maintain, so you should only optimize what needs to be optimized.
Any optimization that you know with 100% certainty ahead of time will make a huge difference and won't complicate your code hugely. This actually includes more than you might think, but there's still not a lot of optimizations that fall into this category.
Update: One area that may need some planning is interaction with the database. In particular, you need to plan to query as much as you can as soon as you can if you're going to be doing a lot of queries. Making several small queries when you could instead be using one big query can be a huge performance drag, and it can cause some major architectural redesign if you don't design your architecture with this in mind. As always, your true milage may vary.
Algorithm and data structure must align with the problem. This isn't "optimization". This is "design".
Getting the right algorithm/data structure is central, essential and first.
Generally, you want to avoid or minimize search. This isn't optimization; this is simple design of a data structure that avoids search. Hash tables, trees, indexes, and what-not are design issues, not optimizations.
You want to avoid or minimize sort. This isn't optimization, either. This is simple design of the right algorithm to prepare the data in a way that doesn't require sorting. Trees, linked lists, priority queues, heaps, and what-not are design issues.
After you have prevented searching and sorting, there isn't much left that really eats up mountains of time. If you still have performance problems after preventing all searching and sorting, feel free to optimize what's left.
I would say if your are storing/searching any type of data, do the following:
Optimize immediately for readability and maintainability. Measure performance. Don't optimize for performance unless you have measurement and can tell in hard numbers what the effect of your optimizations are.
Edit: To add clarification:
Anything that affects high-level design. In practice, a big one tends to be reducing memory allocations, because without the ability to freely heap allocate, a lot of programming techniques are out the window at a design level. Also, if a data structure that's passed around a lot is hard to encapsulate in a way that hides the implementation you might want to make sure it's efficient early on.
Read C++ Optimizations You Can Do "As You Go" chapter in this useful reminder website.
And don't forget that you can have a good early optimization by choosing a good enough algorithm from the start. Make sure your algorithms are well encapsulated, to make a potential refactoring or algorithm change later easy.
Don't write a database access layer that causes thousands of database calls for every click in the UI.
There are several trends that occur:
If you look at these trends individually they tell you different things about whether/when you should optimize. So I don't think there's a general answer.
But in many cases it makes sense to rapid-prototype selected functions of software, forget about optimization unless it's an obvious necessity for the thing to function, then that gets you the ability to try it out and measure performance, study it, and then throw it away so you can do a better job architecting your software for real.
First rule: all data/tables in the database model will be (at least) in boyce-codd normal form. The latter you'll be in optimizing your database, the closer you'll be to hell.
Immutability in objects.
I call it the best optimisation there is.
There probably is no single optimization trick that should always be done early. As always pointed out, any specific tricks should wait until you have analyzed your performance.
You should however, as S.Lott pointed out, consider performance in your design, from the first minute.
That does not mean any specific optimization, but planning your performance. Specifically, identify:
Then you should calculate a rough performance estimate. If that looks good, you're fine. If it looks like you will miss your performance goals, you should not continue to the next stage until you have a design that has at least a fighting chance of meeting the goals. Otherwise, you're setting yourself up for failure.
The idea is not to get a design that is guaranteed to perform well, but to avoid a design that cannot perform properly (as in "we'll just do everything in RAM", but the database has 2 TB). Any performance problems that you were unable to foresee that way can then be dealt with when they occur.
I personally agree with sleske's answer; a lot of software suffers from bad performance because nobody on the team sets performance goals (e.g., when the project starts, or as new features are conceived). For example, how fast do you want a particular action to take (from, say, the user's perspective)? 5 seconds? 1 second? Less? If you can't answer that question, you probably aren't going to end up with good performance in the end. For one thing, it's hard to set up systematic performance tests without any goals for them to measure against. At best, you'll have to engage in costly refactoring to finally achieve adequate performance (after, say, your customers complain enough, or your competitors come out with faster software).
More generally, there is a great article about optimization in the ACM's Ubiquity publication, The Fallacy of Premature Optimization. It is the best article I've read on this subject; the author makes great points and provides historical context. Here is an excerpt from the final summary:
Sir Tony Hoare's statement "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" has been responsible for a fundamental change in the way software engineers develop applications. A misinterpretation of this statement, particularly the clause "premature optimization is the root of all evil" has led many software engineers (and schools teaching new engineers) to believe that optimization and, indeed, concern about software efficiency, is unimportant. To reverse the decline in application performance, software engineers must first reject the prevailing attitude that performance is not important. Once they decide that writing efficient software is worthwhile, the next step is to learn how high-level language compilers and interpreters process those high-level constructs; once the engineer understands this process, choosing appropriate high-level constructs will become second nature and won't incur additional development cost. Hoare's statement, in its original context, certainly still applies. Premature optimization, at the microscopic level, is usually a bad idea. This does not suggest, however, that engineers should not be concerned about application performance. The fallacy that "premature optimization" is the same thing as "concern about performance" should not guide software development.
Based on my experience from various, mostly negative, experiences around optimizations as a software developer and architect.
Do (and make sure the team does):
Do not:
From a database perspective, there are a lot of things that are known to be faster most of the time in querying. For instance, avoiding writing cursors is not a premature optimization it is good design. There are three things which are critical to database development: security, data integrity and performance. If you are not considering the performance of every query you write, then you are doing a bad job. You don't have to optimize to the nth degree, but you should think every time, is this the best performing way to do this query. Once you learn the techniques which perform better they are not harder to maintain or understand. If you don't consider performance when writing queries then your application will work badly and will ultimately fail. Users consider performance as one of their highest priorities and developers should do the same.
And I'm with mjmarsh, if you aren't testing against a dataset as large or larger than you expect the application to have, you are not doing your job. It isn't premature to consider how normal performance will be. What works OK in a small dataset is immediately shown to be a problem in a large dataset.