

Node.js module performance - sorenso
http://litt.no/tech%20stuff/javascript_module_performance

======
antouank
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
Great work!

In newer versions of the V8 engine the global opt is not de-optimized.

Thanks for testing! -sorenso-

~~~
antouank
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
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
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 :)

------
brwnll
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
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 :)

------
PSeitz
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
I'm not sure I understand your concerns. Can you please elaborate?

~~~
PSeitz
Since you wouldn't use something like this it in practice, it's hard to
extrapolate the results to a real scenario.

------
sorenso
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 :)

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

~~~
sorenso
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-

------
arenaninja
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
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-

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

~~~
sorenso
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-

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

~~~
sorenso
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
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
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-

