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