"Systems have so much memory, it doesn't matter if I increase memory usage for simplicity or maintainability."
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.
In this case I think the tradeoff is not worthy. We're not in the 80s anymore and its ok for a desktop to load an app icon with an additional file access. Even more if its a well known vector format.
Imagine what would have happened if HTML had been a non human-readable binary format just to spare a few bytes.
We're not in the 80s anymore and its ok for a desktop to load an app icon with an additional file access.
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.
Imagine what would have happened if HTML had been a non human-readable binary format just to spare a few bytes.
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."
Early in my career I heard just such advice from a guy I respected as a big success in his field.
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.
There is a difference between doing the right thing for efficiency, and going out of your way to make things as fast as possible. Storing 1k entries in an O(n) datastructure is an example of not doing the former, and using your language's built-in hashmap type, instead of implementing your own, using domain-specific knowledge to optimize it within an inch of life, is an example of the ladder.
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.
In my experience, "mildly optimised" code tends to be simpler and more efficient in terms of the effort required to maintain it too. Anyone who has compared a compiler's -O0 to its -O1 will likely come to the same conclusion. It's only at the "-O2" and above where the effort starts becoming significant.
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 80/20 rule tends to give you significantly different returns on optimization, depending on what code you optimize. Then, there are other priorities to consider, like optimizing for programmer reads. By all means, if you can write easier to understand code by writing efficient code, then do so.
"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.
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.
Data size usually is the constraining factor in performance. Loading memory from your SSD, loading it through the internet. Processing it: the smaller the data the lower in the cache hierarchy it will sit, copying data is expensive, less data means less register pressure.
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.
It is often not worth the effort.