I've spent a lot of time jumping in to optimise horrendously complicated programs and data pipelines and things. The big wins are from understanding the domain and spotting all the inevitable misunderstandings and unnecessary steps that creep in when systems are so big they get split up and built/maintained by different people at different times.

Optimize for maintainable (readable) code with sane, understandable flows. then optimize for the user experience. Processors complete lifetimes when a human blinks. If you're doing /meaningful/ work with those cycles, that's fine. If it's bloat... trim bloat.

The blog post is really good. I see that there's a follow-up piece 'The Fifth Kind of Optimisation' about parallelism.

Something that I'd like to add is that it's helpful to understand the optimization capabilities of our compiler. Ideally, we would like to write program that doesn't have what are called 'optimization-blockers' - these make it hard for the compiler to generate optimized executables.

I like the pointer to the blog on accidentally quadratic implementations. I find that the following pattern is often a landmine:

for (int i = 0; i < strlen(s); i++) // code in loop

strlen(s) gets computed every iteration, incurring O(n) time.

Finally, being aware that I/O latencies are major source of bottlenecks leads to nice optimizations. One advantage of multiple threads is that they can sometimes hide the I/O latency. In general, writing programs with good memory locality is one of the better levers for optimization.

This is missing the 5th and most important optimization technique: don't pessimize the code in the first place.

The usual culprit is "premature modularization", where code that is used in one place and is never going to be extended is nonetheless full of indirections.

Python is not something I expect to see when talking about performance. Being interpreted with powerful builtins it distorts what is fast and what isn’t in a fairly unpredictable way.