I come from a DBA world and performance has always been an obsession. I am turning to development and I always think about performance, constantly, all the time.
Reading
I think there are two contradictory proverbs that are relevant here.
1: Premature optimization is the root of all evil.
2: Look before you leap.
In my personal experience, it has been the case that when code is first written, the probability of finding the magic 3% of the code that is using 90% of the resources is very easy to find. This is where the first proverb is relevant, and seems to produce great results. As the code base matures however, it seems to be that instead of 3% using 90% of the resources, you suddenly have 50% using 90% of the resources. If you imagine the analogy of a water pipe, instead of a few big leaks, you now have the problem of multiple small leaks, all over the place. This gives the overall application slow performance, even if its hard to pin down to any one individual function.
This is where proverb 2 seems relevant. Don't rely on the first proverb to not do any performance planning, have an overall plan, even if it an evolving one. Try work out some acceptable performance metrics and time your program. Consider the later performance implications of design choices. As an example, one might plan to use a tuple store rather than a database in advance if all that is needed is a tuple store. Starting with an SQL database and then changing to a tuple store later is quite difficult.
Above all, do try to optimize where its easy and make notes about cases where optimization is possible. If you don't, as time goes on, programs tend to suffer the death of a thousand cuts, as the effect of functions that are 5-20% slower than they need to be add up and indeed multiply.