Linkbait. "Aren't the teats the only interesting part of a cow?" Uhh, sure, yes, you get the milk from that, I don't know if I'd define "interesting" that way.<p>As for his actual argument. Depends on the application. If you run 20 lines of code, no loops, for 2mil clients on one server, that 20 lines matters. If that 20 lines includes one line which requires a lock, maybe only that one line matters. Maybe I analyze a graph structure (oh, the social web) and my loop is a loop per say not not anything that can be easily optimized without knowing the topology. The slow part of your loop can be the loop body. Or not --- it can be the allocation/deallocation cost of data structures. Parallelism can be fast --- or the concurrency weight can be crushing. I'm not saying that parallelism isn't a huge win. I'm saying the question is invalid or trivial.<p>Point is, the generalization here isn't wrong; generalization here is wrong.
What code <i>isn't</i> running in some sort of "loop"? As I have discovered when, e.g., writing test build code, that function which "only runs once" actually gets run several times per day, or several times per coder per day, or (when you are debugging or testing new code) several dozen times per hour.<p>Because every function is potentially callable from within someone else's loop, there is no such thing as a function that isn't part of a loop. There are merely frequent loops and less- frequent loops; it's a question of degree. Unless it's a function that really does never get run, in which case, yes, nobody cares if your dead code is slow.
If you're compute bound and are trying to optimize for performance, then sure, you only need to worry about loops.<p>One way to think about this is that if you need optimize something, it's only because a particular task is taking at least a few seconds to execute. A few seconds means a few billion instructions on a modern CPU. There aren't any executables with billions of instructions of straight-line code so your code surely has a loop (or a million loops).<p>However, as many others have pointed out, this CPU-centric view won't give any insight into optimizing I/O bound applications.
Isn't that simplifying things a bit? Loops are hidden everywhere, just concatenating a string is actually a loop even if there's no visible for/where, but the best optimization for that isn't speeding up the loop, it's removing the call completely.
With unlimited resources, it's the code only executed once that becomes the performance issue. Amdahl's law shows that you can't run faster than the sequential sections.
<i>In fact, I can argue that any time we wait on a computer program to do something useful, we are in fact waiting on a loop</i><p>Plenty of things are bound by I/O. You might have to wait for a disk to spin up, or a packet to get to the other side of the world and back. Indeed, the CPU will, at some level, ultimately be running in a loop, but it's not a loop in order to get anything done, it's just blocking.