3 ms·

If you start talking to most programmers about efficiency, you’ll almost immediately be shut down with “premature optimization is the root of all evil” (no matt

If you start talking to most programmers about efficiency, you’ll almost immediately be shut down with “premature optimization is the root of all evil” (no matter how non-premature the optimization might be). There’s a pervasive belief among programmers that hardware is so fast that, as long as the software works, it doesn’t matter how efficiently it uses memory, or CPU, or disk space, or the network… yet the #1 complaint I hear from software _users_ is “damn, this thing is slow”. I yearn for a day when we start behaving like real professional engineers and strive to make the most efficient use of resources.

tijsvd 7y ago
That quote about premature optimization is from 1974. Back then, manually tweaking code to produce the "right" machine instructions really mattered. But it was time-consuming and hard, and hence should be applied only to the most time-sensitive part of a program. Today, we get that kind of optimization, for the whole program, simply by adding -O2 to our build options, and waiting slightly longer for the compiler to complete. Engineers using that quote are an important reason for the failure of software projects. Not only should we make efficient use of resources, but performance of software must be taken into account right from the beginning of any software project. Performance requirements must be clear from the start (how many concurrent users, how many requests per second, etc., times 2 (or 20) for safety) and when a design is made, performance requirements for each individual component should be set (and measured after implementation).
lubujackson 7y ago
I am always surprised by devs that have a strong sense for O notation and how it affects code complexity, but have no clue about the bloat in tools or libraries they throw on the pile. So version 1.0 comes around and they immediately need to refactor to get down from a 15 second page load (or from a huge file/data stream). Fine tuning code is one thing, but installing a bloated package for one tiny feature should be well-considered at the time of implementation because every addition adds to the tech debt bill.
tombert 7y ago
In fairness, I feel like we have closer to a Gustafson's law [0] situation; individual tasks haven't gotten much faster, but it feels like we do more than we did in the 90s. The problem space has gotten so much larger than it used to be, and at some level we got to "fast enough" for things like desktop applications. Not to mention, programs are so much more stable nowadays; I can't remember the last time my computer just locked up for no apparent reason, and I am typically pretty happy that most programs don't leak memory all over the place anymore. Are a lot of programs bloated now? Sure, but I think I'd rather have that than having my program crash all the time because someone who didn't really know what they're doing cleared a pointer incorrectly. [0] https://en.wikipedia.org/wiki/Gustafson%27s_law https://en.wikipedia.org/wiki/Gustafson%27s_law
- igouy 7y ago
  You'd rather have bloated programs than some random not-necessarily connected bad-thing?
  - tombert 7y ago
    It's not necessarily connected, but often connected. GCs introduce some level of bloat, but they also give stronger guarantees of memory safety. There are a lot more programmers out there now than there were 20 years ago, and with that we're going to inherently have more bad programmers writing bad programs. If they aren't good programmers, I don't trust them to handle memory correctly. I know languages like Rust and Swift have ways of safely dealing with memory without a GC, and I know Go has a non-blocking GC now, but remember that all of these things are relatively recent.
    - kbenson 7y ago
      > I know languages like Rust and Swift have ways of safely dealing with memory without a GC Those are very different things, to my knowledge. Rust is "no-GC" in the vein of C and C++ (but the borrow checker makes the memory management portion easier to deal in that you generally don't have to manually free stuff). Swift is "memory managed" in that is uses reference counts to automatically check through the used variables and free ones that are no longer references. In my eyes, that's pretty clearly a type of garbage collection, even if it seems the term has become specific enough that it's less often applied to that case.
weberc2 7y ago
I like faster and smaller, but it sounds like we are striving to make the most efficient use of resources, including developer time. "professional engineers" don't have to worry so much about this because the costs of their projects aren't dominated by their own salaries as ours are.
AnIdiotOnTheNet 7y ago
The modern developer cares for only their own time, their own money, and their own fun. User concerns aren't even on the list.
- userbinator 7y ago
  I agree completely, except for the "fun" part --- what developer enjoys waiting for gargantuan projects to compile, slow tools to respond, or debugging through a byzantine maze of dependencies and indirection bloat? ...unless it's this sort of fun, perhaps? https://xkcd.com/303/ https://xkcd.com/303/
tastyfreeze 7y ago
Sure, the number one requirement is to get the job done. But, nobody that takes pride in their work is going to be satisfied with fat, slow code. Efficient code is a thing of beauty that takes time to craft. Unfortunately, our desire to make beautiful things gets crushed under the constant race to production of the next feature.
dwild 7y ago
> #1 complaint I hear from software _users_ is “damn, this thing is slow”. I strangely hear that quite often too on morning traffic ;). When will theses real professional engineers will learn?!?!?! > make the most efficient use of resources Can you define this? Everything can be done more efficiently. A real professional engineers won't do premature optimization. You won't see bridges using some amazing new carbon material, it's not only too costly for the budget, it's also not needed (the bridge does everything it has to do per the requirement). A real professional engineers will do the most he can with the resource he has, which is pretty much what we do in software engineering.
MaulingMonkey 7y ago
IME the discussion is almost immediately rekindled if you have actual perf numbers to back it up, or a specific 10 second fix to turn O(scary) code into O(1) code. Over the years I have wasted a lot of time reviewing or discussing "optimizations" that didn't help - or even hurt - performance. Micro-optimizing some once-off init function instead of tackling major per-frame overhead and stuttering. Creating a nice lean core site and then burdening it with a billion third party scripts requested by marketing. 30MB matters for a website, or keyboard firmware. On the other hand, my gamedev workloads often crash on 32GB machines. I measure useful SSD sizes in TB. In that context, 30MB is line noise. A rounding error. You could spend a lifetime optimizing more important performance issues, and still never turn your attention to that 30MB as something useful to spend time reducing further.
franga2000 7y ago
I yearn for a day when a manager will approve a month-long rewrite of the app fronted in something sensible just to save 200MB of RAM. "The developer who wrote the MVP had 2 web dev courses and a week to write it from scratch, now all of you with your CS degrees want to spend a month making it smaller?" The fact of the matter is that quality simply does not matter in today's world. Not in software, not in hardware, not in food, clothing, cars, or basically any other area. It's all about minimizing costs.
paulddraper 7y ago
And yet its remarkable how many user shop for features, not performance. Try to make software good enough to sell, and that is quickly the obvious conclusion.
hcarvalhoalves 7y ago
The quote was about not sweating about the most efficient solution first, and instead focusing on getting it correct, because you can easily fall into the trap of optimising for the wrong thing before profiling and making bad trade-offs on complexity and maintainability. Nothing about the original quote was related to Turing's law.

tijsvd 7y ago

That quote about premature optimization is from 1974. Back then, manually tweaking code to produce the "right" machine instructions really mattered. But it was time-consuming and hard, and hence should be applied only to the most time-sensitive part of a program. Today, we get that kind of optimization, for the whole program, simply by adding -O2 to our build options, and waiting slightly longer for the compiler to complete. Engineers using that quote are an important reason for the failure of software projects. Not only should we make efficient use of resources, but performance of software must be taken into account right from the beginning of any software project. Performance requirements must be clear from the start (how many concurrent users, how many requests per second, etc., times 2 (or 20) for safety) and when a design is made, performance requirements for each individual component should be set (and measured after implementation).

lubujackson 7y ago

I am always surprised by devs that have a strong sense for O notation and how it affects code complexity, but have no clue about the bloat in tools or libraries they throw on the pile. So version 1.0 comes around and they immediately need to refactor to get down from a 15 second page load (or from a huge file/data stream). Fine tuning code is one thing, but installing a bloated package for one tiny feature should be well-considered at the time of implementation because every addition adds to the tech debt bill.

tombert 7y ago

In fairness, I feel like we have closer to a Gustafson's law [0] situation; individual tasks haven't gotten much faster, but it feels like we do more than we did in the 90s. The problem space has gotten so much larger than it used to be, and at some level we got to "fast enough" for things like desktop applications. Not to mention, programs are so much more stable nowadays; I can't remember the last time my computer just locked up for no apparent reason, and I am typically pretty happy that most programs don't leak memory all over the place anymore. Are a lot of programs bloated now? Sure, but I think I'd rather have that than having my program crash all the time because someone who didn't really know what they're doing cleared a pointer incorrectly. [0] https://en.wikipedia.org/wiki/Gustafson%27s_law https://en.wikipedia.org/wiki/Gustafson%27s_law

igouy 7y ago
You'd rather have bloated programs than some random not-necessarily connected bad-thing?
- tombert 7y ago
  It's not necessarily connected, but often connected. GCs introduce some level of bloat, but they also give stronger guarantees of memory safety. There are a lot more programmers out there now than there were 20 years ago, and with that we're going to inherently have more bad programmers writing bad programs. If they aren't good programmers, I don't trust them to handle memory correctly. I know languages like Rust and Swift have ways of safely dealing with memory without a GC, and I know Go has a non-blocking GC now, but remember that all of these things are relatively recent.
  - kbenson 7y ago
    > I know languages like Rust and Swift have ways of safely dealing with memory without a GC Those are very different things, to my knowledge. Rust is "no-GC" in the vein of C and C++ (but the borrow checker makes the memory management portion easier to deal in that you generally don't have to manually free stuff). Swift is "memory managed" in that is uses reference counts to automatically check through the used variables and free ones that are no longer references. In my eyes, that's pretty clearly a type of garbage collection, even if it seems the term has become specific enough that it's less often applied to that case.

weberc2 7y ago

I like faster and smaller, but it sounds like we are striving to make the most efficient use of resources, including developer time. "professional engineers" don't have to worry so much about this because the costs of their projects aren't dominated by their own salaries as ours are.

AnIdiotOnTheNet 7y ago

The modern developer cares for only their own time, their own money, and their own fun. User concerns aren't even on the list.

userbinator 7y ago
I agree completely, except for the "fun" part --- what developer enjoys waiting for gargantuan projects to compile, slow tools to respond, or debugging through a byzantine maze of dependencies and indirection bloat? ...unless it's this sort of fun, perhaps? https://xkcd.com/303/ https://xkcd.com/303/

tastyfreeze 7y ago

Sure, the number one requirement is to get the job done. But, nobody that takes pride in their work is going to be satisfied with fat, slow code. Efficient code is a thing of beauty that takes time to craft. Unfortunately, our desire to make beautiful things gets crushed under the constant race to production of the next feature.

dwild 7y ago

> #1 complaint I hear from software _users_ is “damn, this thing is slow”. I strangely hear that quite often too on morning traffic ;). When will theses real professional engineers will learn?!?!?! > make the most efficient use of resources Can you define this? Everything can be done more efficiently. A real professional engineers won't do premature optimization. You won't see bridges using some amazing new carbon material, it's not only too costly for the budget, it's also not needed (the bridge does everything it has to do per the requirement). A real professional engineers will do the most he can with the resource he has, which is pretty much what we do in software engineering.

MaulingMonkey 7y ago

IME the discussion is almost immediately rekindled if you have actual perf numbers to back it up, or a specific 10 second fix to turn O(scary) code into O(1) code. Over the years I have wasted a lot of time reviewing or discussing "optimizations" that didn't help - or even hurt - performance. Micro-optimizing some once-off init function instead of tackling major per-frame overhead and stuttering. Creating a nice lean core site and then burdening it with a billion third party scripts requested by marketing. 30MB matters for a website, or keyboard firmware. On the other hand, my gamedev workloads often crash on 32GB machines. I measure useful SSD sizes in TB. In that context, 30MB is line noise. A rounding error. You could spend a lifetime optimizing more important performance issues, and still never turn your attention to that 30MB as something useful to spend time reducing further.

franga2000 7y ago

I yearn for a day when a manager will approve a month-long rewrite of the app fronted in something sensible just to save 200MB of RAM. "The developer who wrote the MVP had 2 web dev courses and a week to write it from scratch, now all of you with your CS degrees want to spend a month making it smaller?" The fact of the matter is that quality simply does not matter in today's world. Not in software, not in hardware, not in food, clothing, cars, or basically any other area. It's all about minimizing costs.

paulddraper 7y ago

And yet its remarkable how many user shop for features, not performance. Try to make software good enough to sell, and that is quickly the obvious conclusion.

hcarvalhoalves 7y ago

The quote was about not sweating about the most efficient solution first, and instead focusing on getting it correct, because you can easily fall into the trap of optimising for the wrong thing before profiling and making bad trade-offs on complexity and maintainability. Nothing about the original quote was related to Turing's law.