4 ms·

Awaiting “something, something premature optimization” person to show up in the comments.

hinkley 3y ago
You’d think they would catch on. But then a foolish consistency is the hobgoblin of little minds.
zogrodea 3y ago
"In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering." - Also Knuth
- eru 3y ago
  A 12% overall improvement might be worthwhile. But you have to look at the bigger picture: if part A of your project takes 99.9% of the time, and part B takes 0.1% of the time, even a 100% improvement in part B (ie making it take 0 time) might not be worthwhile.
  - jackthetab 3y ago
    a.k.a. [Amdahl's Law](https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law)
- jononor 3y ago
  I agree. But it is critical to ensure that what one is improving is something worthwhile. 12% improvement in compute costs for a project with lots of compute spend = massive win. 12% improvement in compute costs for a hobby project running on a single VM = probably negligible. 12% improvement in function runtime some arbitrary place in the stack = possibly net negative, taking into account developer opportunity costs. It is almost always useful to talk in terms of outcomes, ie benefits to customer/users/team/company.
- erk__ 3y ago
  The original quote is not by Knuth, though he made it well known, it is by Tony Hoare.
- matheusmoreira 3y ago
  Any improvement is significant!! I spent a week implementing an optimization for my language (pypy's storage strategies) and ended up significantly slowing it down instead. It's not guaranteed. I have massive respect for anyone who can pull off steady improvements, no matter how small.
cogman10 3y ago
Lol, yeah I get this quoted sometimes merely for suggesting the right data structure to use. "Use a set instead of a list, it's faster". "that's premature optimization!"
- saagarjha 3y ago
  Usually this criticism doesn't even hold water if you put performance aside, since a set will often have nicer ergonomics if you find yourself reaching for it. I see far too much code that is like items.remove((item) => item == value) and if you're using the proper datastructure you don't have to handroll your implementations each time, because they are provided by default.
- _dain_ 3y ago
  Premature pessimization.
- The_Colonel 3y ago
  The real premature optimization is using List instead of Set for guaranteed small sizes, since List is going to outperform Set in those cases.
  - marcellus23 3y ago
    That depends on how list and set are implemented.
- neandrake 3y ago
  Except in your example I’ve had numerous cases where bugs have been introduced because the developer’s primary thinking to pick a set was “fast” and “no duplicates”, only to later realize that order of items is important. And looking back at their choice, dealing with 5-20 items, using a list and checking contains() not only had no performance impact but better reflects the intent of “no duplicates”. Instead the set is left in place and the dev fixing it usually copies the results in a list to be sorted the same order prior to being in the set...
  - 3y ago
_dain_ 3y ago
People always seem to think "premature optimization" means "premature optimization for speed". But there are lots of otherwise-good things that you can prematurely optimize for: - modularity - readability - abstraction - maintainability - scalability - reusability - testability - cost We've all seen codebases that are over-abstracted in the name of code reuse, or to adhere to this or that software design philosophy, and are nightmares as a result. "You Ain't Gonna Need It" is a restatement of the premature-optimization adage, just for a different metric.
- whstl 3y ago
  And the "premature optimization" excuse is used almost every time someone argues that over-abstraction can cause performance issues.
  - hinkley 3y ago
    Or other forms of laziness.
- munch117 3y ago
  "Premature optimisation" refers to speed or size. Using the phrase to talk about those other things is a stretch. (Except maybe cost.) You can design for modularity, readability etc., but optimising for them doesn't sound right. Something to do with them not having well-defined, agreed-upon definitions of where the optimum is.
  - hinkley 3y ago
    I work with a Principle of Maximum Power guy. He’s insufferable. Too smart to browbeat into behaving, and too old to chalk it up to youthful exuberance or lack of experience. He’s made big chunks of the project comfortable for him and miserable for everyone else, so of course he’ll never leave, and people who know they deserve better do.
  - chriswarbo 3y ago
    I think it's fair to talk about optimisation (premature or otherwise) for anything fitting Blum's axioms. The classic ones are number of instructions executed, wall-clock time, memory usage, network requests, user interactions, calls to some slow function (e.g. the comparison function, for sorting algorithms), etc. but I think it's also applicable to fuzzier concepts. For example, modularity could be modelled as the time/edit-distance/etc. it would take to swap-out N out of C components, where C >> N. If we're defining things centrally and passing them around via dependency-injection then it's O(N) (each component is defined once, so change N of them); if we're hard-coding references everywhere then it's O(N*C) since we'll have to check for references in all of the components, and each one needs to be checked for the N possible swaps. On the other hand, dependency injection is less optimal than hard-coding for a metric like API size: for N components, the number of references grows as O(N^2) (since new components need to reference existing ones, and existing ones will need to reference them); so APIs using DI will have O(N^2) arguments.

You’d think they would catch on. But then a foolish consistency is the hobgoblin of little minds.

"In established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering." - Also Knuth

eru 3y ago
A 12% overall improvement might be worthwhile. But you have to look at the bigger picture: if part A of your project takes 99.9% of the time, and part B takes 0.1% of the time, even a 100% improvement in part B (ie making it take 0 time) might not be worthwhile.
- jackthetab 3y ago
  a.k.a. [Amdahl's Law](https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law)
jononor 3y ago
I agree. But it is critical to ensure that what one is improving is something worthwhile. 12% improvement in compute costs for a project with lots of compute spend = massive win. 12% improvement in compute costs for a hobby project running on a single VM = probably negligible. 12% improvement in function runtime some arbitrary place in the stack = possibly net negative, taking into account developer opportunity costs. It is almost always useful to talk in terms of outcomes, ie benefits to customer/users/team/company.
erk__ 3y ago
The original quote is not by Knuth, though he made it well known, it is by Tony Hoare.
matheusmoreira 3y ago
Any improvement is significant!! I spent a week implementing an optimization for my language (pypy's storage strategies) and ended up significantly slowing it down instead. It's not guaranteed. I have massive respect for anyone who can pull off steady improvements, no matter how small.

cogman10 3y ago

Lol, yeah I get this quoted sometimes merely for suggesting the right data structure to use. "Use a set instead of a list, it's faster". "that's premature optimization!"

saagarjha 3y ago
Usually this criticism doesn't even hold water if you put performance aside, since a set will often have nicer ergonomics if you find yourself reaching for it. I see far too much code that is like items.remove((item) => item == value) and if you're using the proper datastructure you don't have to handroll your implementations each time, because they are provided by default.
_dain_ 3y ago
Premature pessimization.
The_Colonel 3y ago
The real premature optimization is using List instead of Set for guaranteed small sizes, since List is going to outperform Set in those cases.
- marcellus23 3y ago
  That depends on how list and set are implemented.
neandrake 3y ago
Except in your example I’ve had numerous cases where bugs have been introduced because the developer’s primary thinking to pick a set was “fast” and “no duplicates”, only to later realize that order of items is important. And looking back at their choice, dealing with 5-20 items, using a list and checking contains() not only had no performance impact but better reflects the intent of “no duplicates”. Instead the set is left in place and the dev fixing it usually copies the results in a list to be sorted the same order prior to being in the set...
- 3y ago

_dain_ 3y ago

People always seem to think "premature optimization" means "premature optimization for speed". But there are lots of otherwise-good things that you can prematurely optimize for: - modularity - readability - abstraction - maintainability - scalability - reusability - testability - cost We've all seen codebases that are over-abstracted in the name of code reuse, or to adhere to this or that software design philosophy, and are nightmares as a result. "You Ain't Gonna Need It" is a restatement of the premature-optimization adage, just for a different metric.

whstl 3y ago
And the "premature optimization" excuse is used almost every time someone argues that over-abstraction can cause performance issues.
- hinkley 3y ago
  Or other forms of laziness.
munch117 3y ago
"Premature optimisation" refers to speed or size. Using the phrase to talk about those other things is a stretch. (Except maybe cost.) You can design for modularity, readability etc., but optimising for them doesn't sound right. Something to do with them not having well-defined, agreed-upon definitions of where the optimum is.
- hinkley 3y ago
  I work with a Principle of Maximum Power guy. He’s insufferable. Too smart to browbeat into behaving, and too old to chalk it up to youthful exuberance or lack of experience. He’s made big chunks of the project comfortable for him and miserable for everyone else, so of course he’ll never leave, and people who know they deserve better do.
- chriswarbo 3y ago
  I think it's fair to talk about optimisation (premature or otherwise) for anything fitting Blum's axioms. The classic ones are number of instructions executed, wall-clock time, memory usage, network requests, user interactions, calls to some slow function (e.g. the comparison function, for sorting algorithms), etc. but I think it's also applicable to fuzzier concepts. For example, modularity could be modelled as the time/edit-distance/etc. it would take to swap-out N out of C components, where C >> N. If we're defining things centrally and passing them around via dependency-injection then it's O(N) (each component is defined once, so change N of them); if we're hard-coding references everywhere then it's O(N*C) since we'll have to check for references in all of the components, and each one needs to be checked for the N possible swaps. On the other hand, dependency injection is less optimal than hard-coding for a metric like API size: for N components, the number of references grows as O(N^2) (since new components need to reference existing ones, and existing ones will need to reference them); so APIs using DI will have O(N^2) arguments.