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

Great work!

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

Thanks for testing! -sorenso-

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 ( 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.

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-

I've made some changes to the scripts and pushed all to a github repo: 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 :)

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

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

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.

I'm not sure I understand your concerns. Can you please elaborate?

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

If you want, you can run these test yourself: https://github.com/5orenso/javascript-module-performance

I'll then present the results on a nice webpage :)

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

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-

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

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-

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

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-

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

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.

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.

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-