3 ms·

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,

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.
    - SomeCallMeTim 12y ago
      > 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. That's true enough, though it doesn't seem to be the original point, since the context refers to optimizing parts of the code that aren't taking most of the time. Which is a danger, but I think the danger is in wasting time on such optimizations, either up front or through increased complexity.
  - vinceguidry 12y ago
    I use Ruby and love it. I've never had to write anything truly performant with it, but I will enjoy the challenge of writing a C extension when the time finally comes. The reason I love it is because it offers really, really powerful ways of handling crazy amounts of abstraction. I'm absolutely willing to pay a performance penalty if it means I can, when I really start to need the performance, refactor the code in a day to where I can replace the needed bits with a C extension, and then spend the next day writing said extension. Assuming a C extension is even called for. For something like a server, what I would do is, with Ruby, nail down the one thing that server needs to do, say, take requests and write them to a database. Then write that exact server in short and sweet Go or C++. In fact, I can easily envision a time in the not-too-distant future where the broad strokes of my coding practices are set down and I'm down to refining them so they work faster and better, working towards a clean mix of Ruby and C where I can refactor concepts into and out of both languages as needed. With Ruby, I can spend less time implementing and more time thinking hard about my domain model. Ruby is not ugly to me, it's incredibly beautiful, particularly its object model. It's great because I can write ugly code to make something work with an eye towards making it easy to clean up later. When I write something ugly, I know that there's a domain concept that is going to need to be let out at some point, the wonderful thing is that I don't have to do it immediately. Ruby lets me manage a monstrous mess of interrelated concepts and abstractions, manage the process of starting ugly and iterating towards clean. And I can do it all by myself. I see nothing wrong with choosing to start with a faster language if that's where your skills lie. But you can pry Ruby from my cold, dead hands. Does Ruby scale? I wouldn't want to try with anything else. It's not just connections per second that needs to scale, it's everything else too.

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.
  - SomeCallMeTim 12y ago
    > 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. That's true enough, though it doesn't seem to be the original point, since the context refers to optimizing parts of the code that aren't taking most of the time. Which is a danger, but I think the danger is in wasting time on such optimizations, either up front or through increased complexity.
- vinceguidry 12y ago
  I use Ruby and love it. I've never had to write anything truly performant with it, but I will enjoy the challenge of writing a C extension when the time finally comes. The reason I love it is because it offers really, really powerful ways of handling crazy amounts of abstraction. I'm absolutely willing to pay a performance penalty if it means I can, when I really start to need the performance, refactor the code in a day to where I can replace the needed bits with a C extension, and then spend the next day writing said extension. Assuming a C extension is even called for. For something like a server, what I would do is, with Ruby, nail down the one thing that server needs to do, say, take requests and write them to a database. Then write that exact server in short and sweet Go or C++. In fact, I can easily envision a time in the not-too-distant future where the broad strokes of my coding practices are set down and I'm down to refining them so they work faster and better, working towards a clean mix of Ruby and C where I can refactor concepts into and out of both languages as needed. With Ruby, I can spend less time implementing and more time thinking hard about my domain model. Ruby is not ugly to me, it's incredibly beautiful, particularly its object model. It's great because I can write ugly code to make something work with an eye towards making it easy to clean up later. When I write something ugly, I know that there's a domain concept that is going to need to be let out at some point, the wonderful thing is that I don't have to do it immediately. Ruby lets me manage a monstrous mess of interrelated concepts and abstractions, manage the process of starting ugly and iterating towards clean. And I can do it all by myself. I see nothing wrong with choosing to start with a faster language if that's where your skills lie. But you can pry Ruby from my cold, dead hands. Does Ruby scale? I wouldn't want to try with anything else. It's not just connections per second that needs to scale, it's everything else too.