3 ms·

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 addi

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.
- SomeCallMeTim 12y ago
  I love the idea of Ruby. I was using Ruby before Rails, and it was my favorite language for a time. But I write code in LuaJIT that's typically as clean as or cleaner than the equivalent Ruby code, as well as already approaching the speed of C, so I don't even need to rewrite it to be performant later. But by all means, if the tool works for you, use 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.

SomeCallMeTim 12y ago
I love the idea of Ruby. I was using Ruby before Rails, and it was my favorite language for a time. But I write code in LuaJIT that's typically as clean as or cleaner than the equivalent Ruby code, as well as already approaching the speed of C, so I don't even need to rewrite it to be performant later. But by all means, if the tool works for you, use it.