Ask HN: How do you approach the trade-offs of code readability and performance? - varrock
======
necovek
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.

------
the_hoser
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.

------
ramsj
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.

~~~
AnimalMuppet
Adding compute is _usually_ cheaper than adding engineers. Probably not for
Google, though, at least not on some projects.

~~~
ramsj
Agreed. But I'm putting those in the 0.1% bucket! :)

------
smt88
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.)

