Is there a line between readability vs compile or processing speed?

Aside from the extreme cases, I wouldn't think it would be even worth saving that little bit extra in favor of legibility...

For example; a bad idea, in my opinion would be removing all the comments on a 'finished' product to gain a little extra speed.

  • Please tell me you meant compiling would be a tiny bit faster and not that running it would be faster if you remove the comments
    – TheLQ
    Commented Jun 9, 2011 at 4:19
  • @TheLQ Yeah I meant compiling, but my mindset at the time was web app based. Apologies temporary loss of mind
    – MattyD
    Commented Jun 9, 2011 at 4:33
  • 1
    Related Question: programmers.stackexchange.com/questions/82221/…
    – blubb
    Commented Jun 9, 2011 at 9:05
  • Back when the first home computers were coming out, most used some form of Microsoft BASIC, and comments and extra whitespace did hurt performance. Commented Jun 9, 2011 at 14:48

3 Answers 3


In most cases you don't have to sacrifice readability to have a well-performing code.

It's all a matter of choosing the right data structures and algorithm for the job. Most of the cases with poorly performing code are caused by the developer not understanding the structures he/she uses.

A good example of such behavior that I commonly see is the overuse of List in C# and vector in C++ - for a lot of programmer these two data structures are the only way to express "a bunch of T" or a "collection of T". Where some other structures like linked lists or trees that are contained in well-abstracted and conveniently implemented classes would do the same thing but with lower magnitude of complexity.

Another example is using huge locks statements / large critical sections, where in reality locking/protecting only one or two of lines of code would be more than enough.

Yet another example that I had to deal with last week when I had to optimize some code was, when the original code needed to import about 5000 xml files to the database, but it had only to import one field of it contained in the very first 100 bytes of the file. Instead of using XmlReader and just reading until reaching that field, that code was loading the whole xml into XmlDocument and calling X-Path on it. The execution time was cut to about 1/30 of the original code and I would say, that the latter version was more readable and maintainable.

Writing more performant code is just a matter of understanding the fundamental algorithms and data structures behind the implemented abstractions in the provided frameworks. It's very rare (and I mean really rare) to see a code that needs highly unreadable code (like assembly) to do the same job but faster.

  • 3
    That's a very good point, and one that I overlooked. Choosing the right tool (algorithm, data structure, library) for the job. At that point, you begin making memory/space trade-offs by choosing one option out of several.
    – Thomas Owens
    Commented Jun 9, 2011 at 2:16
  • 1
    Just curious, how else do you store "a bunch of T"? Is there a better way than a list?
    – user541686
    Commented Jun 9, 2011 at 3:45
  • 5
    A hash table? A tree? A set? It depends on what your data is, what operations are dominant (inserting vs quiring etc.), or god knows what other factor. Thats why we have this entire "Computer Science" thing, so we could use right algorithm/data structure. Commented Jun 9, 2011 at 10:51
  • Of these only set has semantics of bunch of things.
    – Basilevs
    Commented Aug 25, 2015 at 17:30

Readability always comes first. Once you have high quality code, you can test that against your requirements. If performance does not meet the requirements, you can profile the system and determine where the worst performing sections are. From there, you can optimize for speed while still maintaining the highest amount of readability as possible.

I'm also a huge proponent of the system-level view. You don't optimize without profiling the system or subsystem and you only optimize as much as you need to without compromising the readability and maintainability of the code. Humans have to deal with your work in the future - think of them.

As a brief aside...

For example; a bad idea, in my opinion would be removing all the comments on a 'finished' product to gain a little extra speed.

Comments have nothing to do with speed. Removing comments to save space or speed is useless. You might save bytes in the source files, but you shouldn't have to worry about running out of disk space where you save your source files.

  • That's the exact view point, but being a self-taught kiddie, I could have been wrong.
    – MattyD
    Commented Jun 9, 2011 at 2:14
  • Comments in a javascript files require time to download, and time to parse. Both could lead to a few nanoseconds lost.
    – user281377
    Commented Jun 9, 2011 at 8:58
  • @ammoQ True. That said, I've done very little web development, but typically, there are two JavaScript files - the fully commented and readable one and the minimized one which is designed to reduce size. Developers working on the script don't touch the minimized file.
    – Thomas Owens
    Commented Jun 9, 2011 at 10:33
  • Thomas: true, but that kinda proves my point, doesn't it`? Developers would use a minimizer if there wasn't something to gain.
    – user281377
    Commented Jun 9, 2011 at 10:45
  • !ammoQ In JavaScript (along with HTML and CSS), you are dealing with sending the file over a network. You are trying to improve that performance with minimization. The question is referring to the performance of the code itself - my understanding there's no difference in performance between the minimized code and the original code, once it has been delivered to the client. Therefore, minimization has nothing to do with the optimization of the code, a separate issue all together.
    – Thomas Owens
    Commented Jun 9, 2011 at 10:52

Comments in a javascript files require time to download, and time to parse. Both could lead to a few nanoseconds lost. – ammoQ

That is a valid point, however, there are tools to minify javascript that can be run as part of a build process. So for the development of the code, you can have good names and comments where necessary etc to keep the dev process as simple as possible. When a release build is made the comments can be stripped, along with unnecessary whitespace, and maybe have thatLongAndHelpfulDescriptiveVariableNameButWhichTakesALotOfBytes turned into x to give both extra size reduction power and a bit of free obfuscation :)

Not the answer you're looking for? Browse other questions tagged or ask your own question.