Everybody knows that:

1. Premature optimization is evil
2. Still, you can't just do things the easiest way and "think about the performance later" (late optimization is evil)
3. 80/20 rule applies - apps tend to spend 80% of time in 20% of the code

If you are a developer listening to this advice you probably wonder - when is the right time to optimize? It can't be too early, can't be too late and it only applies to the relatively small piece of code.

You have to think about performance all the time, but not too hard. If you continuously make sure that the code is  right and not unnecessarily slow, you will be in position to the real tuning after you've measured where the bottlenecks are. The kind of "optimization" that you do continuously is not really a performance tuning as much as it is trying not to hurt the performance.

For example, if you know that you will need to keep data in a structure, there will be a lot of it and that you will do frequent lookups, it makes sense to pick a hash map (dictionary) instead of list or vector (array). If you have a loop that is obviously in the critical path, it makes sense to avoid calling expensive functions and precompute that just before the loop (if possible of course). If you have just a little bit of data that is not critical why not keep it in memory and not on the hard drive?

All this is just plain common sense, not performance tuning. But what you intend to is to have a reasonably good solution once you do start measuring and tuning.