3 ms·

Also the premature optimisation quote is not taken out of context, unless he doesn't think "premature" means the same as everyone else.

by Marazan 12y ago

SomeCallMeTim 12y ago
It's the extreme that people take that quote to that causes the problem. He explicitly mentions library development as a place that you always want to optimize, because libraries are often used in inner loops. When developers totally ignore optimal code practices, bad things can happen. Things like 25000 (!) string allocations for each character typed in the Chrome "omnibox". [1] That's not likely one small bit of code with a few std::string's being allocated, but probably dozens or hundreds of (albeit minor) fixes spread throughout the code. It is absolutely worthwhile to code optimally as a habit, when the optimal coding practice isn't significantly harder to implement or understand than the suboptimal practice. (In the above case, having a "pass all strings as const references" would have likely prevented most of the allocations.) Similarly, the way you architect a product can strongly influence how easily it can be optimized. I've cut processing time down from 10's of minutes to under a second on some tasks, just by improving how the code was written -- and that approach means that when I write servers, I can handle all the likely traffic I'll ever see on a handful of servers instead of having to create additional layers of complexity to handle dozens of servers working in parallel. So I disagree that "premature" optimization is a bad thing, by the typical definition of "premature." [1] https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/EUqoIz2iFU4/kPZ5ZK0K3gEJ https://groups.google.com/a/chromium.org/forum/#!msg/chromiu...
- kbenson 12y ago
  I think the point is that you can optimize while writing code, but be leery of optimizing while designing. To a greater or lesser degree depending on the person, task or goal, designing and coding may end up being close to the same thing, which confuses the issue. In real terms, writing perfomant code is good, but packing data structures in interesting ways and optimizing in other manners when you aren't even sure you know all the data you need to store yet is often counter-productive.
  - SomeCallMeTim 12y ago
    I think optimizing while designing is totally appropriate. In fact you can make some of the most powerful optimizations at the design stage, with almost no additional effort required. Should you go down a rabbit hole, spending hours optimizing something because you think it might help? No, of course not. To my reading, that is what the warning is about. But when you're designing a system, especially one that you know needs to be fast, should your design be optimized from the ground up? Yes, in some cases at least. [1] When I code, I choose to use languages (C++, Go, LuaJIT, JavaScript/Node) that allow me to write code that ends up faster. Some people will cite "premature optimization" based solely on that decision, and they'll write their code in Python, or PHP, or Perl, or Ruby. [2] Since my servers will handle 3000 user interactions per second with no caching, I still contend that this is an appropriate stage for optimization. I've seen projects fail because the server requirements were too high: 100 concurrent users per Python-based server on a free-to-play game meant that if the app took off, it would be losing money because of the costs of running hundreds of servers. You can't just "optimize" the app if the problem is you need to rewrite it in a completely different language. Computer time in the cloud may seem cheaper than programmer time, but in practice if you pay the programmers up front to do it right, you can cut ongoing operating costs indefinitely. And sometimes that can mean the difference between a project that succeeds and one that fails. [1] http://gamesfromwithin.com/data-oriented-design http://gamesfromwithin.com/data-oriented-design [2] It looks like at least Ruby has a server that uses a similar strategy to Node or Nginx+LuaJIT: http://www.akitaonrails.com/2014/10/19/the-new-kid-on-the-block-for-ruby-servers-raptor http://www.akitaonrails.com/2014/10/19/the-new-kid-on-the-bl... -- but Ruby and Rails are ugly for a million other reasons, in addition to being slow, so I still would shun it.
    - kbenson 12y ago
      I would contend that in the successful cases where you are optimizing from the beginning, you are actually doing a two stage process, one design stage where you figure out what you need, and another where you figure out how to do that efficiently and fast. To some degree, it's semantics (when is optimization not design related?), but my point was that optimization before nailing down the requirements for that component is what leads to problems. I think that's the premature in premature optimization, when you spend time optimizing something you aren't sure will even survive a later point in the design stage.
yoklov 12y ago
Most people take it to mean "Don't optimize if you don't need to", but he actually means it as "Don't optimize until you know which parts are slow". The missing context is where he talks about (or implies, it's been a while since I read it) how you should always optimize your programs when you're done. IMO these days even the first is bad advice if taken literally. You need to ensure you don't work yourself into a design that cannot be optimized without being rewritten, which is unfortunately a problem I've seen a lot.
- mpweiher 12y ago
  Actually, it is "don't micro-optimize until you know the parts that are slow". You need to do design-/architectural level optimizations from the start.

Also the premature optimisation quote is not taken out of context, unless he doesn't think "premature" means the same as everyone else.

by Marazan 12y ago

Also the premature optimisation quote is not taken out of context, unless he doesn't think "premature" means the same as everyone else.

SomeCallMeTim 12y ago

It's the extreme that people take that quote to that causes the problem. He explicitly mentions library development as a place that you always want to optimize, because libraries are often used in inner loops. When developers totally ignore optimal code practices, bad things can happen. Things like 25000 (!) string allocations for each character typed in the Chrome "omnibox". [1] That's not likely one small bit of code with a few std::string's being allocated, but probably dozens or hundreds of (albeit minor) fixes spread throughout the code. It is absolutely worthwhile to code optimally as a habit, when the optimal coding practice isn't significantly harder to implement or understand than the suboptimal practice. (In the above case, having a "pass all strings as const references" would have likely prevented most of the allocations.) Similarly, the way you architect a product can strongly influence how easily it can be optimized. I've cut processing time down from 10's of minutes to under a second on some tasks, just by improving how the code was written -- and that approach means that when I write servers, I can handle all the likely traffic I'll ever see on a handful of servers instead of having to create additional layers of complexity to handle dozens of servers working in parallel. So I disagree that "premature" optimization is a bad thing, by the typical definition of "premature." [1] https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/EUqoIz2iFU4/kPZ5ZK0K3gEJ https://groups.google.com/a/chromium.org/forum/#!msg/chromiu...

kbenson 12y ago
I think the point is that you can optimize while writing code, but be leery of optimizing while designing. To a greater or lesser degree depending on the person, task or goal, designing and coding may end up being close to the same thing, which confuses the issue. In real terms, writing perfomant code is good, but packing data structures in interesting ways and optimizing in other manners when you aren't even sure you know all the data you need to store yet is often counter-productive.
- SomeCallMeTim 12y ago
  I think optimizing while designing is totally appropriate. In fact you can make some of the most powerful optimizations at the design stage, with almost no additional effort required. Should you go down a rabbit hole, spending hours optimizing something because you think it might help? No, of course not. To my reading, that is what the warning is about. But when you're designing a system, especially one that you know needs to be fast, should your design be optimized from the ground up? Yes, in some cases at least. [1] When I code, I choose to use languages (C++, Go, LuaJIT, JavaScript/Node) that allow me to write code that ends up faster. Some people will cite "premature optimization" based solely on that decision, and they'll write their code in Python, or PHP, or Perl, or Ruby. [2] Since my servers will handle 3000 user interactions per second with no caching, I still contend that this is an appropriate stage for optimization. I've seen projects fail because the server requirements were too high: 100 concurrent users per Python-based server on a free-to-play game meant that if the app took off, it would be losing money because of the costs of running hundreds of servers. You can't just "optimize" the app if the problem is you need to rewrite it in a completely different language. Computer time in the cloud may seem cheaper than programmer time, but in practice if you pay the programmers up front to do it right, you can cut ongoing operating costs indefinitely. And sometimes that can mean the difference between a project that succeeds and one that fails. [1] http://gamesfromwithin.com/data-oriented-design http://gamesfromwithin.com/data-oriented-design [2] It looks like at least Ruby has a server that uses a similar strategy to Node or Nginx+LuaJIT: http://www.akitaonrails.com/2014/10/19/the-new-kid-on-the-block-for-ruby-servers-raptor http://www.akitaonrails.com/2014/10/19/the-new-kid-on-the-bl... -- but Ruby and Rails are ugly for a million other reasons, in addition to being slow, so I still would shun it.
  - kbenson 12y ago
    I would contend that in the successful cases where you are optimizing from the beginning, you are actually doing a two stage process, one design stage where you figure out what you need, and another where you figure out how to do that efficiently and fast. To some degree, it's semantics (when is optimization not design related?), but my point was that optimization before nailing down the requirements for that component is what leads to problems. I think that's the premature in premature optimization, when you spend time optimizing something you aren't sure will even survive a later point in the design stage.

yoklov 12y ago

Most people take it to mean "Don't optimize if you don't need to", but he actually means it as "Don't optimize until you know which parts are slow". The missing context is where he talks about (or implies, it's been a while since I read it) how you should always optimize your programs when you're done. IMO these days even the first is bad advice if taken literally. You need to ensure you don't work yourself into a design that cannot be optimized without being rewritten, which is unfortunately a problem I've seen a lot.

mpweiher 12y ago
Actually, it is "don't micro-optimize until you know the parts that are slow". You need to do design-/architectural level optimizations from the start.