NodeJS: 4.8x Faster if You go Back to Callbacks!

> Remove as much `function` calls as you can and it will run much faster. 

\
That’s such an incredible optimisation. I didn’t appreciate how much function calls were an overheard to performance!

\
Thanks for sharing that! 

You’re very kind. I need to try Bun properly too.

I ran out of space in my previous comment. :sweat_smile: So I’m just continuing here:

\
```javascript
import fs from 'node:fs'; 

const MAX = 10000
let list = []
let doneCount = 0;

console.time()
for (let i = 0; i < MAX; i++) {
    list.push(fs.readFile('./text.txt', () => {
        doneCount += 1
        if (doneCount === MAX) {
            console.timeEnd()
        }
    }))
}
```

\
I again sought out the fastest run:

```javascript
while true; do node parallel.callback.mini.mjs; done
```

\
And here are my results:

\
```javascript
default: 93.75ms
default: 95.241ms
default: 90.282ms
default: 96.667ms
default: 92.648ms
default: 96.69ms
default: 91.109ms
default: 96.202ms
default: 90.788ms
default: 94.838ms
default: 92.592ms
default: 93.823ms
default: 94.6ms
```

\
I’ll admit, this isn’t truly parallel as in concurrency, but it’s apples to apples which is much better.

\
**I still get 2x faster** with parallel callbacks than I do with parallel promises. **It’s not** **4x** though so this is a **fairer** comparison.

\
But yes, I’m still wondering as to why.

\
And thank you again for helping me improve the benchmarks. Id love to update it again once I’ve had the opportunity to compare the runtime on difference machines.

\
It’ll help me understand how the event loop achieves its performance gains.

Hi again.

\
I wanted to thank you for pointing that out and that I was comparing different implementations. Very true.

\
I decided to *load* things into a list for both :sweat_smile: and thought I’d see the same results you mentioned, but there’s still a difference. So I’m intrigued and looking forward to understanding why.

\
**The promises version**

\
This time I decided to remove `node:test` as someone alluded to it polluting the behaviour. So I wanted to remove that from the equation as well.

\
```javascript
import fs from 'node:fs/promises'; 

const MAX = 10000
let list = []
let doneCount = 0;

console.time()
for (let i = 0; i < MAX; i++) {
    list.push(fs.readFile('./text.txt').then(() => {
        doneCount += 1
        if (doneCount === MAX) {
            console.timeEnd()
        }
    }))
}
```

\
I ran the following to try and get the fastest observable time on my machine which may be very different on another machine due to factors I’d love to test:

\
```javascript
while true; do node parallel.promises.mini.mjs; done
```

\
Results:

```javascript
default: 200.56ms
default: 196.285ms
default: 196.592ms
default: 201.183ms
default: 193.663ms
default: 195.988ms
default: 195.783ms
default: 192.086ms
default: 196.096ms
default: 194.861ms
default: 197.478ms
default: 194.716ms
default: 197.915ms
default: 197.482ms
default: 198.243ms
default: 195.585ms
default: 197.2ms
default: 197.853ms
```

\
…

\
\
\


Thank you so much for comment. You many good points I overlooked! I truly appreciate that:

\
> In Node.js code you are using assert.strictEquals (which is a separate function call) to test content integrity while in Go code you are using basic operators for that purpose (hence, no additional function calls, no additional interaction with the call stack). I think you see where I am going with this.

\
Yeah. I see what you’re saying now. I will need to readdress these benchmarks with this in mind as well. Either I need to have a function call in Golang or I use basic asserts in Nodejs which is a fairer comparison. Very true! :ok_hand:

\
> like having an array to store all promises or whatever adds another 10k push function calls and another 10k-ish memory interactions to run.

\
That’s clear now. You explained that very well. Thank you. The results aren’t consistent in that matter.

\
> Please prove me wrong:)

\
I don’t think I will prove you wrong :pray::laughing: as what you said makes sense for my small brain. I’m still very interested in comparing the results as I’ve shamefully worked with Nodejs for years, but only now am I trying to learn deeper concepts, and more broader language concepts such as memory management. 

\
Many appreciations.

\
\


Thanks for the comment.

\
> Promise vs async vs callback have the same performance, your test is flawed in that it doesn't test all the same way. 

\
\
Are you saying the for-loop is the cause of the performance issues and I should just stick to recursion?

\
Do you have example test case we can use alternatively?

\
But good point. I should stick to recursion or for-loops. The only issue is that non-blocking code cannot be blocked in a for-loop. The only way is to nest callbacks within each other. So perhaps I’ll use recursion for all in a future test.

\
\
\
\


Gemma Black