If you have to start thinking about performance, you're in trouble. You should be thinking about performance all the time. In fact, I suspect good programmers are going to think about performance even when they didn't intend to, in a «men think about sex every seven seconds» fashion..
What is important is what actions you will take based on all that thinking. Thoughts are cheap, but actions can break code and blow deadlines.
Most of the time, the only sensible action will be to do nothing: you identified that your piece of code is not going to be called often enough for performance issues to be observable—maybe it's a piece of startup code that runs once per computer for 1% of your potential user base, maybe it's a small bit of redundant server code drowned in a sea of slow database accesses, maybe it's just an integer assignment in a non-critical section of code.
Quite often, you suspect that a given operation might cause a performance issue that could be solved by a simple change. There's for instance, the nagging feeling that running a complex SQL query on every request, or a asking for the same piece of data from a dictionary twice, is going to be bad for you. This is where knowledge of optimization techniques comes in handy, and perhaps the most surprising conclusion happens:
If you know of a quick technique that will almost certainly improve the performance of a piece of code, don't do it.
If you can think of it now, you can certainly do it in five minutes later on. Keeping it out of the code (but, perhaps, in a
// TODO comment) leaves the code cleaner and saves you previous time to work on another feature, while wasting no time if you end up throwing that code away later on. If the original code does turn out to cause performance issues when tested, go back and apply your quick technique.
I'm not saying here that you should avoid writing code that's idiomatic just because it happens to be faster. Write idiomatic code according to best practices that improve productivity and readability and reduce bugs. It's just that if you have a choice between idiomatic by-the-book code and a faster but easily written alternative, always go for readability instead of speed.
The only difficult situation is when there seems to be no easy way to improve code performance, and yet it's painfully obvious that a piece of code is going to break as soon as it's delivered—a full database traversal on every click, a hundred SQL requests per page on the site, or anything similarly dreadful. This is where you actually need to stop and think some more. These are usually architecture issues that cannot be solved on a local scale anyway. Confirm your suspicions with a quick spike or prototype, look for similar experiences and common solutions, and consider either a change of architecture or a drop of features.