6 ms·

> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server. They rewrote the entire codebase

> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server. They rewrote the entire codebase and obtained for just a 25% gain? It doesn't sound like they are very happy to be coding in javascript now either. Everyone: please don't rewrite your code, it's almost never worth it. The one exception is rewriting a core part of an algorithm in C for speed (the last 10x speedup).

omarkj_ 14y ago
There are other reasons for rewriting like getting to a more easily maintainable code or when a previous solution has simply outlived it's usefulness. Also, C is not the only language worth rewriting in.
- voidlogic 14y ago
  "Also, C is not the only language worth rewriting in" Agreed! I would really like to see someone write a node.js and Go back-end for the same front-end and do a head to head comparison. As someone who spent a fair amount of time rewriting node.js prototypes in Go, I'm probably biased. I feel like javascript is a much less maintainable language. Perhaps is was the original node.js implementations (I don't think it was), but the Go versions were always faster, used less memory and IMHO were more readable.
  - iends 14y ago
    Any particular lessons learned rewriting from node to Go? I've got a small but growing node/socket.io app I figured I'd have to one day rewrite in go if I really wanted it to scale.
    - voidlogic 14y ago
      Nothing too unexpected, off the top of my head, I've noticed: * Use Go tip; You can grab a snapshot review all the open issues for that snapshot (most are enhancements). * Like any re-factor doing it sooner as opposed to later is less work :) * Do some "from scratch" Go projects before doing re-factor projects to get your legs under you (if they are not already there) * Write Go in Go, not C/Python/Java in Go. This is harder than you think when you get started, but, if you ask for help and people tell you you are fighting the system, carefully consider their advice. * A lot of the Go community likes to use single letter variable names in contexts like receivers, struct state (just look at the stdlib), buck the system, don't do that, use short camel case names. The next guy / you in six months will be glad you did. * If you have a Java/C++ background you might often write a single threaded version of a daemon and later multithread it later, this is generally an unnecessary step in Go. * The Go versions really are not much larger (LOC) * There is lots of useful Go code on github (don't be afraid to try them) * If you are doing front-endy kind of stuff supplement "net/http" with Gorilla where needed whenever you can rather than rolling your own. ttp://www.gorillatoolkit.org/ * "go tool prof" is a great tool, know how to use it and its top20 / web commands. Even if you don't feel the pain, use it and you will learn what things you do are expensive and it will keep trouble from sneaking up on you. * If you are using a SQL based store, use a driver that implements the interfaces in "database/sql" rather than providing its own interface. This will make your life very simple if you need to migrate between mySQL <-> Postgre, etc * LiteIDE is a nice lean cross platform Go IDE that includes syntax highlighing, autocomplete (with gocode) and debugging support. The only think I had to do was write my own syntax highlighting theme, based on Solarized, because I thought the included ones were gross.
julien 14y ago
Well, the reason we rewrote was not to explode all benchmarks. The reason we rewrote was to be able to ease the maintenance of our code =)
- DoubleCluster 14y ago
  That's fine. Did the code become easier to maintain? It's not clear from the article. The "The good" section is relatively weak and the "The not-so-good" has some painful points about memory management and api instability. It sounds a bit like you guys rewrote it because node.js is hot and you then stuck with the rewrite because of sunk costs. Or am I imagining things? Thanks for sharing your experiences with us. I'm just asking those questions because I want to learn more about them.
  - julien 14y ago
    Well, we assumed everyone knew about the good... so yes, we're happy with the rewrite and will probably never go back. Also, a 25% saving in servers for us translate in several thousands of dollars saved monthly. Not negligible :)
    - octo_t 14y ago
      How much development time did this cost though, when you could have been adding new features and improving the user experience?
      - julien 14y ago
        Hard to assess exactly, but we were not adding feature and improving the user experience mostly because maintaining the previous code base and evolving it was so costly.
    - rartichoke 14y ago
      Yeah but in your article you said you're not even sure if this is because of node. You made some architectural changes in your code base and hinted that might have been a reason for the speed boost too. The article might as well be written as "we refactored our code and got a nice speed boost".
jonpacker 14y ago
They did not say anywhere that the 25% speed gain was the reason they did it...
blacktulip 14y ago
I kind of agree that 25% gain doen't justify codebase rewrite, let along language/framework switching. Perhaps they are doing this with future traffic peak in mind. Premature optimisation, I know. Probably they've already cleared up other important items on their todo list. What interested me most is the community part. I've always thought ruby/rails community is awesome. Maybe I should start learning some JavaScript now.
dnu 14y ago
It depends on how large the code base is. Rewriting a 10k LOC project isn't a big deal, compared to a 10 mln one. And a rewrite doesn't have to target performance only, but ease of maintenance too.
- PommeDeTerre 14y ago
  If ease of long-term maintenance is a goal, then JavaScript is the wrong approach.
  - nkohari 14y ago
    Well that's just, like, your opinion man.
    - gbog 14y ago
      You have better ways to ask for explanations. Not the OP but I can give some reasons for Javascript and Node.js to not be the best option for a rewrite if the goal is longterm maintainability: - js / node.js is very young, it might fade out of fashion, and in 10 years it is not impossible that good coders in js will be hard to find. - Readability and simplicity are prominent in this context, and js has a syntax that is less than optimal in this regard. - Maintenance tooling may be lacking. If I were to choose a language for a project that I new will be big and will need care in 10 or 20 years, I'd hesitate, and maybe choose Java (which I hate) or Python (which I hate less). If in a risk-things mood, I'd give Go a try.
      - OriginalSyn 14y ago
        I don't see how finding JavaScript programmers is going to be a problem in 10 years... even if they started now it would take, at least, that long to fully deprecate the language out of the browser. NodeJS may go away but I think betting on JavaScript going away are some pretty long odds.
      - niggler 14y ago
        Node.js may be young but 98% of the code can be reused (and if you are careful, you probably wrote the fallbacks already). V8 can be built separately. When you understand the zen of javascript and try to write in a consistent manner, JS is more readable than C. I equate these concerns with arguments about how lisp or scheme is unreadable. The ecosystem for tooling is expanding, albeit slowly. However, most of your code probably could be implemented in a way that can be run in browser (e.g. XLS parser: http://niggler.github.com/js-xls/ http://niggler.github.com/js-xls/) which is where I see the real value in node. Aligning the languages means fewer moving parts and potential points of failure (as opposed to having to worry about quirks in implementations of many languages and worrying about features supported in one context but not the other)
viraptor 14y ago
I'd look at it from another side. They took a working project which they knew well and transferred it completely to a different platform. The first "complete" version of the rewrite had 25% more throughput. In that case it's a pretty good achievement, since the rewrite will have a lot more low-hanging fruit regarding performance improvements, than a polished, existing product. I'm used to see rewrites which are at least a little bit worse than previous versions due to all the work done to squeeze everything out of version N-1.
nivertech 14y ago
I think the reason they only got 25% gain is because they already used Async IO with Ruby eventmachine. Another reason might be, that their workload is IO-bounded, so faster VM like V8 doesn't help.
- jahewson 14y ago
  If the initial version was IO-bound wouldn't they get a 0% gain from re-writing?
  - diroussel 14y ago
    If my program reads a file one byte at a time, and it's IO-bound, can I improve performance by re-writing?
    - jahewson 14y ago
      Then it's not really IO-bound is it? It's stupidity-bound. Once you re-write it properly then it'll be IO-bound.
Peaker 14y ago
My experience is the exact opposite. Trying to make do with horrible code for long periods of time, suffering through bugs in every change... Until we finally rewrite it. I've never regretted a rewrite, and it has always ended up significantly better than the original (possibly because the horror threshold for rewriting is high, so that's not saying much).
- DoubleCluster 14y ago
  In my experience it's quite doable (with a good IDE) to refactor the working but messy code into something maintainable. It might take the same amount of time as a rewrite but you'll still have all the features and corner cases covered. Usually refactoring will be much faster though.
  - Peaker 14y ago
    I disagree. Incremental changes are not always capable of reaching point B from point A. A large, extremely messy code-base can make even trivial changes unsafe, let alone large changes. The effort required not only to figure out what point B is, but also how to safely reach it from point A is immense. Much much harder than a rewrite. However, it is a very good idea to meticulously read the bad old code and write down a list of things it handles -- to make sure none of it is missed in the rewrite.

omarkj_ 14y ago

There are other reasons for rewriting like getting to a more easily maintainable code or when a previous solution has simply outlived it's usefulness. Also, C is not the only language worth rewriting in.

voidlogic 14y ago
"Also, C is not the only language worth rewriting in" Agreed! I would really like to see someone write a node.js and Go back-end for the same front-end and do a head to head comparison. As someone who spent a fair amount of time rewriting node.js prototypes in Go, I'm probably biased. I feel like javascript is a much less maintainable language. Perhaps is was the original node.js implementations (I don't think it was), but the Go versions were always faster, used less memory and IMHO were more readable.
- iends 14y ago
  Any particular lessons learned rewriting from node to Go? I've got a small but growing node/socket.io app I figured I'd have to one day rewrite in go if I really wanted it to scale.
  - voidlogic 14y ago
    Nothing too unexpected, off the top of my head, I've noticed: * Use Go tip; You can grab a snapshot review all the open issues for that snapshot (most are enhancements). * Like any re-factor doing it sooner as opposed to later is less work :) * Do some "from scratch" Go projects before doing re-factor projects to get your legs under you (if they are not already there) * Write Go in Go, not C/Python/Java in Go. This is harder than you think when you get started, but, if you ask for help and people tell you you are fighting the system, carefully consider their advice. * A lot of the Go community likes to use single letter variable names in contexts like receivers, struct state (just look at the stdlib), buck the system, don't do that, use short camel case names. The next guy / you in six months will be glad you did. * If you have a Java/C++ background you might often write a single threaded version of a daemon and later multithread it later, this is generally an unnecessary step in Go. * The Go versions really are not much larger (LOC) * There is lots of useful Go code on github (don't be afraid to try them) * If you are doing front-endy kind of stuff supplement "net/http" with Gorilla where needed whenever you can rather than rolling your own. ttp://www.gorillatoolkit.org/ * "go tool prof" is a great tool, know how to use it and its top20 / web commands. Even if you don't feel the pain, use it and you will learn what things you do are expensive and it will keep trouble from sneaking up on you. * If you are using a SQL based store, use a driver that implements the interfaces in "database/sql" rather than providing its own interface. This will make your life very simple if you need to migrate between mySQL <-> Postgre, etc * LiteIDE is a nice lean cross platform Go IDE that includes syntax highlighing, autocomplete (with gocode) and debugging support. The only think I had to do was write my own syntax highlighting theme, based on Solarized, because I thought the included ones were gross.

julien 14y ago

Well, the reason we rewrote was not to explode all benchmarks. The reason we rewrote was to be able to ease the maintenance of our code =)

DoubleCluster 14y ago
That's fine. Did the code become easier to maintain? It's not clear from the article. The "The good" section is relatively weak and the "The not-so-good" has some painful points about memory management and api instability. It sounds a bit like you guys rewrote it because node.js is hot and you then stuck with the rewrite because of sunk costs. Or am I imagining things? Thanks for sharing your experiences with us. I'm just asking those questions because I want to learn more about them.
- julien 14y ago
  Well, we assumed everyone knew about the good... so yes, we're happy with the rewrite and will probably never go back. Also, a 25% saving in servers for us translate in several thousands of dollars saved monthly. Not negligible :)
  - octo_t 14y ago
    How much development time did this cost though, when you could have been adding new features and improving the user experience?
    - julien 14y ago
      Hard to assess exactly, but we were not adding feature and improving the user experience mostly because maintaining the previous code base and evolving it was so costly.
  - rartichoke 14y ago
    Yeah but in your article you said you're not even sure if this is because of node. You made some architectural changes in your code base and hinted that might have been a reason for the speed boost too. The article might as well be written as "we refactored our code and got a nice speed boost".

jonpacker 14y ago

They did not say anywhere that the 25% speed gain was the reason they did it...

blacktulip 14y ago

I kind of agree that 25% gain doen't justify codebase rewrite, let along language/framework switching. Perhaps they are doing this with future traffic peak in mind. Premature optimisation, I know. Probably they've already cleared up other important items on their todo list. What interested me most is the community part. I've always thought ruby/rails community is awesome. Maybe I should start learning some JavaScript now.

dnu 14y ago

It depends on how large the code base is. Rewriting a 10k LOC project isn't a big deal, compared to a 10 mln one. And a rewrite doesn't have to target performance only, but ease of maintenance too.

PommeDeTerre 14y ago
If ease of long-term maintenance is a goal, then JavaScript is the wrong approach.
- nkohari 14y ago
  Well that's just, like, your opinion man.
  - gbog 14y ago
    You have better ways to ask for explanations. Not the OP but I can give some reasons for Javascript and Node.js to not be the best option for a rewrite if the goal is longterm maintainability: - js / node.js is very young, it might fade out of fashion, and in 10 years it is not impossible that good coders in js will be hard to find. - Readability and simplicity are prominent in this context, and js has a syntax that is less than optimal in this regard. - Maintenance tooling may be lacking. If I were to choose a language for a project that I new will be big and will need care in 10 or 20 years, I'd hesitate, and maybe choose Java (which I hate) or Python (which I hate less). If in a risk-things mood, I'd give Go a try.
    - OriginalSyn 14y ago
      I don't see how finding JavaScript programmers is going to be a problem in 10 years... even if they started now it would take, at least, that long to fully deprecate the language out of the browser. NodeJS may go away but I think betting on JavaScript going away are some pretty long odds.
    - niggler 14y ago
      Node.js may be young but 98% of the code can be reused (and if you are careful, you probably wrote the fallbacks already). V8 can be built separately. When you understand the zen of javascript and try to write in a consistent manner, JS is more readable than C. I equate these concerns with arguments about how lisp or scheme is unreadable. The ecosystem for tooling is expanding, albeit slowly. However, most of your code probably could be implemented in a way that can be run in browser (e.g. XLS parser: http://niggler.github.com/js-xls/ http://niggler.github.com/js-xls/) which is where I see the real value in node. Aligning the languages means fewer moving parts and potential points of failure (as opposed to having to worry about quirks in implementations of many languages and worrying about features supported in one context but not the other)

viraptor 14y ago

I'd look at it from another side. They took a working project which they knew well and transferred it completely to a different platform. The first "complete" version of the rewrite had 25% more throughput. In that case it's a pretty good achievement, since the rewrite will have a lot more low-hanging fruit regarding performance improvements, than a polished, existing product. I'm used to see rewrites which are at least a little bit worse than previous versions due to all the work done to squeeze everything out of version N-1.

nivertech 14y ago

I think the reason they only got 25% gain is because they already used Async IO with Ruby eventmachine. Another reason might be, that their workload is IO-bounded, so faster VM like V8 doesn't help.

jahewson 14y ago
If the initial version was IO-bound wouldn't they get a 0% gain from re-writing?
- diroussel 14y ago
  If my program reads a file one byte at a time, and it's IO-bound, can I improve performance by re-writing?
  - jahewson 14y ago
    Then it's not really IO-bound is it? It's stupidity-bound. Once you re-write it properly then it'll be IO-bound.

Peaker 14y ago

My experience is the exact opposite. Trying to make do with horrible code for long periods of time, suffering through bugs in every change... Until we finally rewrite it. I've never regretted a rewrite, and it has always ended up significantly better than the original (possibly because the horror threshold for rewriting is high, so that's not saying much).

DoubleCluster 14y ago
In my experience it's quite doable (with a good IDE) to refactor the working but messy code into something maintainable. It might take the same amount of time as a rewrite but you'll still have all the features and corner cases covered. Usually refactoring will be much faster though.
- Peaker 14y ago
  I disagree. Incremental changes are not always capable of reaching point B from point A. A large, extremely messy code-base can make even trivial changes unsafe, let alone large changes. The effort required not only to figure out what point B is, but also how to safely reach it from point A is immense. Much much harder than a rewrite. However, it is a very good idea to meticulously read the bad old code and write down a list of things it handles -- to make sure none of it is missed in the rewrite.