Pretty much no software high performance software has gotten there by not thinking about performance&#x2F;optimization until the end. IME what you do is you structure your program so that the optimizations you suspect you will need to make are easy, and can be done without large changes or rewrites to unrelated parts. This does result in more work than being totally naive, but less work than optimizing it ahead of time (you also usually won&#x27;t loose the flexibility you loose when you optimize if you work this way).<p>And while using a profiler is required for optimization, it&#x27;s not the only part. Optimization is a feedback loop between your assumptions and a profiler. Make assumptions, change something, validate the result with the profiler. Assumptions without the profiler can be wrong, and so you need the profiler, however the profiler tends to have an extremely poor signal to noise ratio (especially for code that is already fast, which tends to have a relatively flat profile).<p>Bit of a rant, but while theres truth to premature optimization being bad, and needing to use a profiler, most of the people who say these things mean &#x27;never optimize&#x27; and assume if they have to the profiler will magically solve their problem and tell them exactly what they need to fix, which is rarely true.