3 ms·

If you already know that something has to be fast, then it's not really premature optimization.

• trashtester 4y ago
  I would say, in most cases it pays to make the overall design of the code in a way that enables fast execution. This includes selection of languages and libraries. Identifying loops or recursion with many iterations (high N) with a high Big O order may also be avoided during the design stage, of you KNOW the N and O-order at design time. (And don't worry about the O-order for low N problems, that is premature optimization most of the time.). On the other hand, tweaking every single statement or test in ways that save 1-2 cycles is rarely worth it. Often you end up with obfuscated code that may even make it harder for the compiler to optimize for. This is the 97% of the code where premature optimization makes things harder. Some programmers may turn this on its head. They don't understand the implications of the design choices, but try to make up for that by employing all sorts of tricks (that may or may not provide some small benefit) in the main body of the code.