Comments on: Stop Sacrificing Readability For Efficiency!

By: Dave Walker

Dave Walker — Tue, 07 Apr 2009 17:42:08 +0000

For a personal web project, or for a small internal app, I could not agree with you more. For a site that gets 1+mil hits every hour, i could not disagree with you more. The framework we use at work is huge (powerful) but highly efficient, because we mostly stick to the language constructs. If, however, for every page-load we needed to add to the stack 3k+ function calls to make code ‘readable’ that would probably have a noticeable and detrimental effect of the app as a whole.

While I mostly agree, yes you should write clean, readable code, you can also do what I’ve done, and make a ‘optimization’ parser that takes clean readable code and converts as much as I tell it to do from functions to language constructs.

By: Joshua Ross

Joshua Ross — Wed, 01 Apr 2009 01:10:05 +0000

I am in complete agreement and blogged about this very thing not too long ago… shortly after becoming frustrated at my team for headscratching optimizations and abbreviations of variables/methods/classes. Now if I could only get my team to read our blogs. :)

By: Brandon Savage

Brandon Savage — Tue, 31 Mar 2009 13:10:29 +0000

Andries, I see your point. However, at some point you’re still going to be writing the source code that I found confusing. That said, I like custom true/false functions, and your point has merit.

By: Brandon Savage

Brandon Savage — Tue, 31 Mar 2009 13:08:06 +0000

Since we’re testing for exactly 5 characters, no. The first code sample tests for five characters too.

By: Andries Inzé

Andries Inzé — Tue, 31 Mar 2009 12:38:26 +0000

A good solution is to write an efficient isShorterThen($string, 5).
The isShortThen method can then do the optimized version.

By: Ben

Ben — Mon, 30 Mar 2009 22:01:15 +0000

shouldn’t that be strlen($string) < (rather than ==) ?

By: Jim R. Wilson

Jim R. Wilson — Mon, 30 Mar 2009 21:16:40 +0000

Agreed – it’s definitely a tradeoff.

I tend to do micro-optimizations in the face of something known to loop or be expensive, and leave it more readable otherwise.

For example, in some JavaScript implementations, doing someArray.push(x) is slower than someArray[someArray.length] = x. Neither is especially more readable than the other, so I tend to use the faster version (especially since appending to an array so often happens within a loop).

Also, it might be worth mentioning that code execution itself is rarely the bottleneck – so often it’s file access, or database queries, or some other even more expensive task (such as performing an uncached HTTP request to an external 3rd party web service). Given this, code micro-optimizations like the string length example in the article are generally only going to help the part of the code which is already the fastest.

By: Tibo

Tibo — Mon, 30 Mar 2009 15:04:11 +0000

Interesting post. I think that in quite a lot of cases there’s just no real need to go into these kind of details to gain a little bit of performance boost. And the gain is usually negated by maintenance cost. (Upgrading your server might be cheaper than having a development team waste time).

Besides choice of functions: Imo the availability of good (and free) IDE’s make it easy to use good descriptive (and possibly long) variable names, so on that part there’s no reason for keeping variable names confusingly short.

By: Readability vs. Optimization « I <3 Programming

Readability vs. Optimization « I <3 Programming — Sat, 28 Mar 2009 06:46:05 +0000

[...] There’s a very interesting post up at brandonsavage.net about the relative merits of coding for readability vs coding for optimization. Personally, I agree that could should be readable first and optimized second. There’s no point in having super-optimized code if you can’t maintain it (by which I mean, read it six months after it was written.) Go and have a look. [...]

By: Brandon Savage’s Blog: Stop Sacrificing Readability For Efficiency! : Dragonfly Networks

Sat, 28 Mar 2009 04:51:38 +0000

[...] Savage has a recommendation fro developers out there – sometimes readability is more important than any micro-efficiency you [...]

By: Brandon Savage’s Blog: Stop Sacrificing Readability For Efficiency! : WebNetiques, LLC : Website Developers in Minneapolis, MN

Sat, 28 Mar 2009 04:49:00 +0000

[...] Savage has a recommendation fro developers out there – sometimes readability is more important than any micro-efficiency you [...]

By: Brandon Savage

Brandon Savage — Fri, 27 Mar 2009 19:27:35 +0000

Jay, you’re absolutely right. And, in fact, 10 other developers who I talked to about that blog post failed to notice that, too.

By: Jay Muntz

Jay Muntz — Fri, 27 Mar 2009 19:22:45 +0000

The first example is actually testing for a six-character string. Should be:

if(isset($string[4]) && !isset($string[5]))

And of course – that just proves your point even more. The more-efficient way is also more bug-prone!

By: Giorgio Sironi

Giorgio Sironi — Thu, 26 Mar 2009 17:27:32 +0000

Totally agree… “Let’s rewrite this procedure in assembly…”…

By: Brandon Savage

Brandon Savage — Thu, 26 Mar 2009 15:37:44 +0000

Sebs, I think you misunderstood the example.

I’m not encouraging needless use of else conditions. And you can bet I’d probably wrap that code in a function. But for the sake of the example, I used an else condition simply for the sample.

You raise a very valid point, however; else conditions can be removed for the most part, unless you’re doing unique processing in the else condition.