6 ms·

Node.js module performance

46 points by sorenso 12y ago

jsnoi 12y ago
v2 uses shared opt object, so using another new utils(opt) will override your previous options.
- sorenso 12y ago
  Thanks for your reply! I know, but this is still a common way of making objects. I've seen it several times, but I don't like it ;) -sorenso-
PSeitz 12y ago
Calling prototype functions directly from the constructor function instead on the objects doesn't make much sense. So I'm not sure how to value the results.
- sorenso 12y ago
  I'm not sure I understand your concerns. Can you please elaborate?
  - PSeitz 12y ago
    Since you wouldn't use something like this it in practice, it's hard to extrapolate the results to a real scenario.
stupidcar 12y ago
I don't get it. Why would you care about the performance of your module boilerplate?
- sorenso 12y ago
  Because it's the foundation of all modules and if you start of on the wrong path it can only get worse. On a daily basis I'm working on web applications with more than 5000 req/sec, so it's important to make sure your code performs.
  - stupidcar 12y ago
    Ohhh, I was confused because I know Node caches module objects, but I see the code in the V1 case is creating a new function each time it's used. Seems like it's not really a module issue per se though, just a general JS best practice.
    - sorenso 12y ago
      Yes, version 1 is using closures which creates a new function every time the function is called. I've seen this pattern in many places and even used it myself :) -sorenso-
couchand 12y ago
Is the call to console.log really there in the benchmarked version 3?
- sorenso 12y ago
  Thanks for your comment! I've checked and console.log is not there in the code I ran in my benchmark. I re-ran the tests right now to make sure I didn't screw up this. Best regards, -sorenso-
antouank 12y ago
Tried it on 0.10.36 , 0.12 and io.js 1.4.3 to see difference between node versions. Almost identical results, except for v2, which has a huge difference... https://gist.github.com/AntouanK/ab089b3380a7ff73b8f7 https://gist.github.com/AntouanK/ab089b3380a7ff73b8f7
- sorenso 12y ago
  Great work! In newer versions of the V8 engine the global opt is not de-optimized. Thanks for testing! -sorenso-
  - antouank 12y ago
    A small repo with the files would be useful for other people to run the script. I made one here https://github.com/AntouanK/node-modules-benchmark https://github.com/AntouanK/node-modules-benchmark ( I removed the huge number of tests, I didn't want to wait more than a minute :D ) And maybe a way to get the results would help you see differences between machines and platforms.
    - sorenso 12y ago
      Thanks :) This is a splendid idea. I'm working on this now to be able to capture the results. I'll update the blog post with the repo. -sorenso-
      - sorenso 12y ago
        I've made some changes to the scripts and pushed all to a github repo: https://github.com/5orenso/javascript-module-performance https://github.com/5orenso/javascript-module-performance Please test it and it will post the results to my API which was made in a hurry :)
arenaninja 12y ago
Extremely educational, thanks. I started using Node for some things where PHP feels inadequate (async network requests), and overall I'm happy with the speed, but after years of PHP it's been rough figuring out the right way to do objects. I don't need nearly this many requests, but I find it useful to internalize micro-optimizations to make your code a speed demon
- sorenso 12y ago
  You're welcome! It's good to start with a solid module boilerplate, but you should always consider readability before performance if you don't need the performance. Code maintenance is important :) -sorenso-
sorenso 12y ago
If you want, you can run these test yourself: https://github.com/5orenso/javascript-module-performance https://github.com/5orenso/javascript-module-performance I'll then present the results on a nice webpage :)
brwnll 12y ago
Am I incorrect in my normal usage of "x" when conveying relative performance? With 120.8498 vs 120.4320 being conveyed as "1.00 x slower". Is this the correct terminology for results that are on par with each other? Really, these results are (relatively) unchanged. Shouldn't it be 0.003x slower, with the formula being (Old / New) - 1. From the page: Result Node.js v0.12.0 Called v2, util.yo("man") 100.000.000.000 times in 120.849870219 sec (1.00 x slower than v3) Called v3, util.yo("man") 100.000.000.000 times in 120.432087601 sec
- sorenso 12y ago
  Thanks for your comment. I agree that the semantic of this can be misinterpreted. It should have said "1.00 x the speed of v3". I'll change the text in my next run of this. I'm currently working on a new benchmark test of promises and callbacks. All in the name of performance :)

46 points by sorenso 12y ago

jsnoi 12y ago

v2 uses shared opt object, so using another new utils(opt) will override your previous options.

sorenso 12y ago
Thanks for your reply! I know, but this is still a common way of making objects. I've seen it several times, but I don't like it ;) -sorenso-

PSeitz 12y ago

Calling prototype functions directly from the constructor function instead on the objects doesn't make much sense. So I'm not sure how to value the results.

sorenso 12y ago
I'm not sure I understand your concerns. Can you please elaborate?
- PSeitz 12y ago
  Since you wouldn't use something like this it in practice, it's hard to extrapolate the results to a real scenario.

stupidcar 12y ago

I don't get it. Why would you care about the performance of your module boilerplate?

sorenso 12y ago
Because it's the foundation of all modules and if you start of on the wrong path it can only get worse. On a daily basis I'm working on web applications with more than 5000 req/sec, so it's important to make sure your code performs.
- stupidcar 12y ago
  Ohhh, I was confused because I know Node caches module objects, but I see the code in the V1 case is creating a new function each time it's used. Seems like it's not really a module issue per se though, just a general JS best practice.
  - sorenso 12y ago
    Yes, version 1 is using closures which creates a new function every time the function is called. I've seen this pattern in many places and even used it myself :) -sorenso-

couchand 12y ago

Is the call to console.log really there in the benchmarked version 3?

sorenso 12y ago
Thanks for your comment! I've checked and console.log is not there in the code I ran in my benchmark. I re-ran the tests right now to make sure I didn't screw up this. Best regards, -sorenso-

antouank 12y ago

Tried it on 0.10.36 , 0.12 and io.js 1.4.3 to see difference between node versions. Almost identical results, except for v2, which has a huge difference... https://gist.github.com/AntouanK/ab089b3380a7ff73b8f7 https://gist.github.com/AntouanK/ab089b3380a7ff73b8f7

sorenso 12y ago
Great work! In newer versions of the V8 engine the global opt is not de-optimized. Thanks for testing! -sorenso-
- antouank 12y ago
  A small repo with the files would be useful for other people to run the script. I made one here https://github.com/AntouanK/node-modules-benchmark https://github.com/AntouanK/node-modules-benchmark ( I removed the huge number of tests, I didn't want to wait more than a minute :D ) And maybe a way to get the results would help you see differences between machines and platforms.
  - sorenso 12y ago
    Thanks :) This is a splendid idea. I'm working on this now to be able to capture the results. I'll update the blog post with the repo. -sorenso-
    - sorenso 12y ago
      I've made some changes to the scripts and pushed all to a github repo: https://github.com/5orenso/javascript-module-performance https://github.com/5orenso/javascript-module-performance Please test it and it will post the results to my API which was made in a hurry :)

arenaninja 12y ago

Extremely educational, thanks. I started using Node for some things where PHP feels inadequate (async network requests), and overall I'm happy with the speed, but after years of PHP it's been rough figuring out the right way to do objects. I don't need nearly this many requests, but I find it useful to internalize micro-optimizations to make your code a speed demon

sorenso 12y ago
You're welcome! It's good to start with a solid module boilerplate, but you should always consider readability before performance if you don't need the performance. Code maintenance is important :) -sorenso-

sorenso 12y ago

If you want, you can run these test yourself: https://github.com/5orenso/javascript-module-performance https://github.com/5orenso/javascript-module-performance I'll then present the results on a nice webpage :)

brwnll 12y ago

Am I incorrect in my normal usage of "x" when conveying relative performance? With 120.8498 vs 120.4320 being conveyed as "1.00 x slower". Is this the correct terminology for results that are on par with each other? Really, these results are (relatively) unchanged. Shouldn't it be 0.003x slower, with the formula being (Old / New) - 1. From the page: Result Node.js v0.12.0 Called v2, util.yo("man") 100.000.000.000 times in 120.849870219 sec (1.00 x slower than v3) Called v3, util.yo("man") 100.000.000.000 times in 120.432087601 sec

sorenso 12y ago
Thanks for your comment. I agree that the semantic of this can be misinterpreted. It should have said "1.00 x the speed of v3". I'll change the text in my next run of this. I'm currently working on a new benchmark test of promises and callbacks. All in the name of performance :)