Efficiency vs legibility of code?

Question

Let's say I have a simple function which calculates the cube root of a number and returns it as a string:

def cuberoot4u(number):

    return str(pow(number, 1/3))

I could rewrite this as:

def cuberoot4u(number):
    cube_root = pow(number, 1/3)
    string_cube_root = str(cube_root)
    return string_cube_root

The latter version has the extra steps of declaring extra variables which show the value through each respective operation; multiplying by 1/3 and the conversion to a string - the code looks a little easier to follow and understand.

Now for such a menial task of finding the cuberoot, both functions would appear pretty self-explanatory to the layman. However, if the function did something far more complicated which involved tens or hundreds of algebraic manipulations or some other kinds of operations, at what point should one simply write all of these in the return section of the function or instead detail all, if not most, steps in the main body like the 2nd example above?

To my understanding, the first version of the function seems less legible but more efficient. How and when do I balance legibility against efficiency in code such as in this example?

Answer 1

In general you should prioritise legibility over efficiency in your code, however if you have proved that your codes performance is causing an issue then (and only then) should you start to optimise.

If you do need to make your code less legible in order to speed it up you can always use a comment to explain what it is doing (perhaps even including the more readable version of the code in the comment to allow people to follow what it is doing).

Beware however, one of the problems with explaining your code via a comment rather than by just writing legible code is that comments can become out of date. If you change the code but don't update the comment, then your comment goes from being a helpful commentary to being a weasel-faced liar who ruins everyone's day - try to avoid that if possible.

Answer 2

1. Always prioritize readability first.

2. Always prioritize readability first.

3. Premature optimization is evil. So always prioritize readability first.

4. Once you're readable code is working, if performance is an issue, or if it becomes an issue, profile your code before optimizing anything. You don't want to waste time and reduce readability optimizing something that won't give you much benefit.

5. First optimize things that will still be pretty much as readable after they're optimized; for example, binding methods to local variables.

   1. These will tend to not improve performance too much (though binding methods to local variables can make quite a difference in some code), but sometimes you can see something more efficient and just as readable that you missed before.

   2. Whether X reduction in readability is worth Y increase in performance is subjective and depends on the importance of each in the particular situation.

6. Then, if you still need to optimize, start factoring out the parts of the code you're going to optimize into functions; that way, even after they've been optimized and made less readable, the main code is still readable because it's just calling a function do_something() without worrying about the ugly, optimized blob of code in that function.

   1. I think this can be a good thing to do even with readable code, to make it even more readable.

7. If every tiny bit of performance helps, then you might want to inline the functions back into the main code. This depends on which implementation of Python you're using, e.g. CPython versus PyPy.

8. If one big mass of optimized-to-hell Python code isn't fast enough.. rewrite it in C.

   1. You might just do this anyway, so that your Python code can stay readable and pure, free from the shackles of petty performance concerns.