Oftentimes a developer will be faced with a choice between two possible ways to solve a problem — one that is idiomatic and readable, and another that is less intuitive, but may perform better. For example, in C-based languages, there are two ways to multiply a number by 2:
int SimpleMultiplyBy2(int x) { return x * 2; }
and
int FastMultiplyBy2(int x) { return x << 1; }
The first version is simpler to pick up for both technical and non-technical readers, but the second one may perform better, since bit shifting is a simpler operation than multiplication. (For now, let’s assume that the compiler’s optimizer would not detect this and optimize it, though that is also a consideration).
As a developer, which would be better as an initial attempt?
You missed one.
First code for correctness, then for clarity (the two are often connected, of course!). Finally, and only if you have real empirical evidence that you actually need to, you can look at optimizing. Premature optimization really is evil. Optimization almost always costs you time, clarity, maintainability. You’d better be sure you’re buying something worthwhile with that.
Note that good algorithms almost always beat localized tuning. There is no reason you can’t have code that is correct, clear, and fast. You’ll be unreasonably lucky to get there starting off focusing on `fast’ though.