Ask HN: How do you approach the trade-offs of code readability and performance?

On a case-by-case basis :)

Unfortunately, it's not just the two of them.

In general, I always start with simplest ("most readable" in the sense of easiest to understand) implementation that I have the time to implement (time is another variable).

If a performant version is a no-brainer in terms of cost to implement, and at worst only slightly reduces readability, I'd probably go with that just because I like to be proud of my code (satisfaction in a job is yet another variable).

Ultimately, I rarely find that readability suffers with performant code.

Unreadable code is usually non-performant because it is hard to improve.

Focus on performance sometimes simply reduces how reusable/generic code is, but I don't find readable and performant to be in opposition at all.

Just write readable code. 95% of the time it's more than fast enough. If it's not, then make sure you understand why it's not fast enough before you start making changes. It's very likely that the performance issues have more to do with what you're doing than how you're doing it. Never, ever optimize before measuring.

Always readability, unless you're working on some 0.1% project that absolutely requires bleeding edge performance and latency. Adding compute is cheaper than adding engineers to debug obscure code.

Write the code without considering performance. It should be both readable and easy to refactor.

Then profile your code and determine where to rewrite for performance.

In my experience, big performance optimizations are usually small changes and don't affect readability much.

(Systems-level C/C++ can be exceptions to the above, of course.)