P.S. When I say "optimized code", I really mean "optimized algorithms" ("code" probably isn't the right word at all). When I refer to optimization, I don't mean crafting your code to produce better machine code (that's the compiler's job) - I mean crafting your algorithms to get the job done as effeciently as possible.
Ahh.. that explanation plus your extreme example above clarifies things.
What you're describing I wouldn't term as "un-optimized code", but more along the lines of a code smell and misunderstanding of language syntax.
We're probably in agreement more than I originally suspected.
Ok, but how does this make slower code result in smoother frame rates?
Mostly because it's not so much about the CPU anymore, and more about the graphics card-->driver-->API pipeline. The main CPU acts as a proxy between your application and the API, and much of CPU cycles you're seeing after a graphics call are actually empty event polls (i.e. watching the message queue on windows machines) waiting for the API to return a reponse.
Those are at the very least, 3 levels of failure with exponential potential of difference from machine to machine before it even gets to your compiled code.
I've heard a lot of horror stories of contradictive behavior amongst video cards for certain API calls. I think in the early days of Blitz this was a pretty big headache for Mark. Or at least thats what his work logs seemed to suggest.