The most complicated example I've seen thus far, however, is that of Crash Bandicoot for the PS1.[2] Perhaps the most interesting thing is the description of their efficient code use:
"Ultimately Crash fit into the PS1's memory with 4 bytes to spare. Yes, 4 bytes out of 2097152. Good times." (3)
[1] - http://www.rantgamer.com/wp-content/uploads/2014/12/Clouds-a... [2] - http://all-things-andy-gavin.com/2011/02/02/making-crash-ban... [3] - https://www.quora.com/How-did-game-developers-pack-entire-ga...
It is often not worth the effort.
Now look at your stack and count how many developers could have uttered this phrase when designing each module, subsystem, library, protocol, service, daemon, file type, interface, or plug-in that's part of it.
We should count ourselves lucky that hardware engineers have afforded us the ability to make such trades but we shouldn't take it for granted.
Imagine what would have happened if HTML had been a non human-readable binary format just to spare a few bytes.
Some optimizations are counter productive.
If you want to "just spare a few bytes", you could do the same to HTML and keep it text-based. Comparing something like XML and JSON shows that "human-readable" formats can vary significantly in complexity alone.
Besides, I think we could all do with fewer layers of abstraction in our lives. As a reverse-engineer I know once remarked, "Everything is human readable if you have a hex editor."
Some optimizations are counter productive.
In what context? Also, aren't you making presumptions about new contexts that might appear? We have for decades been in an era where devices get more power efficient and smaller, allowing them to become more ubiquitous. BeOS used to be able to fit a fully kitted OS into under 300MB that could punch way above its weight in terms of multimedia multitasking. Right now computers attached to your body often need to be recharged every day or once a week. Even now, we'd like those computers to be able to do more with even less power.
If I could make a computer so small and cheap, a big company wouldn't care if one is lost occasionally, yet with enough longevity to accompany a freight shipment of package on its entire journey, while recording or even transmitting data, I bet could sell a bunch of those.
Mobile device, network latency?
A couple of years later, when his code started taking down other actors in the ecosystem, it became my job for a while to replace his modules with my own implementations that were more efficient. Sometimes by a factor of 1000. Literally.
Doing it right the first time would have only taken a fraction of the effort it took in the end (assuming you have the proficiency to do so).
I find dismissive comments about efficiency troubling.
Don't write code you know will be too slow, but don't optimize the code just because you can. By the same token, if you find out that your code is too slow, it's your job to optimize it.
Take performance seriously, but don't optimize before you know why you're optimizing.
Of course, different programmers will have different ideas of what "mildly optimised" means; what I mean by "mildly optimised" above is actually the code I'd write as a first pass and consider not optimised at all, and not "the first thing that comes to mind even if it's actually horribly stupidly inefficient" which a lot of programmers seem to do. In other words, my idea of unoptimised is probably more like a -O1, and I'd have to spend extra effort "pessimising" to go below that.
"the first thing that comes to mind even if it's actually horribly stupidly inefficient"
There are certain practices, like the "Law of Demeter" and the "Replace Temp with Query" refactoring that are deliberately inefficient for the purpose of making refactoring and code changes easier. I think of these as being somewhat like a filing system that leaves a little bit of inefficiency to facilitate later reorganization.
This attitude is why we can't have performant smartphones with 1GB of RAM.
It's one thing to do evil floating point bit level hacking and such to save a nanosecond or two, and another to write a FizzBuzz in a way that doesn't require 700 external libraries to begin with.
And performance still sucks for many things. They should be instantaneous (in under one frame, which is ~1.6ms). Loading and parsing SVG files from the internet is one such thing that takes way too long.