I believe the difference here is that these newly introduced promise wrappers allow you to pass an AbortSignal instances to them. Wrapping the old callback style methods would not allow you to "abort" in the middle of reading a file. You could respond to a passed in AbortSignal instance in the simple `readFilePromise` function you provided by simply rejecting early, but it wouldn't free up the underlying file descriptor until after the entire file had been read.

Actually I was completely wrong. They added support for consuming an AbortSignal in the old callback style methods as well. Now I'm at a loss as to why they even have two different implementations instead of just doing something like:

    fs.promises.readFile = util.promisify(fs.readFile);

I agree in principle, but for some reason, the underlying implementation for fs.promises is completely separate.

I think this is where fs.promises.readFile reads the actual file https://github.com/nodejs/node/blob/master/lib/internal/fs/p..., with many layers of indirection before that

fs.readFile is this one function: https://github.com/nodejs/node/blob/master/lib/fs.js#L327-L3...

I'm brand new to the code, but I don't think it is as simple as you state.

The 'one function' you linked to just passes a ReadFileContext into binding.open[1]. The ReadFileContext appears to have its own read that uses its own allocated Buffers[2] under some circumstances, but under others they are mysteriously already there[3]. Then binding.open refers to an internalBinding of fs[4], which I'm unsure of, is that js or C++ code? This[5] suggests C++ is involved, but there is also an open in lib/fs.js[6] with that signature, though it also just calls binding.open at the end with the same signature, so I think it's off into C++ by then. At that point, I lose the trail. Maybe C++ is even doing the allocating.

This is not easy code to grok in its full extent.

1 - https://github.com/nodejs/node/blob/master/lib/fs.js#L356

2 - https://github.com/nodejs/node/blob/master/lib/internal/fs/r...

3 - https://github.com/nodejs/node/blob/master/lib/internal/fs/r...

4 - https://github.com/nodejs/node/blob/master/lib/fs.js#L74

5 - https://github.com/nodejs/node/blob/3b2863db12818778671713b5...

6 - https://github.com/nodejs/node/blob/master/lib/fs.js#L472

edit: I was curious so I kept reading, It seems like open is probably C++ here[7], which makes an AsyncCall or SyncCall to "open", which are just wrappers around syscalls[8]. Still not sure about other places the buffer comes from, though.

7 - https://github.com/nodejs/node/blob/master/src/node_file.cc#...

8 - https://github.com/nodejs/node/blob/606df7c4e79324b9725bfcfe...

On a SSD reading files is fast. However read() is a blocking operation that could take forever - reading some /dev/ device that never returns any data, or a slower medium that takes hundreds of milliseconds per read. That’s a big no-no. So it gets dispatched to a dedicated blocking-io threadpool with limited workers which does the blocking operation without interrupting the event loop.

I’m guessing as disk speeds have increased the relative overhead of dispatching the task to a thread pool has also increased.

At least, that’s how I think it works based on some half-remembered blog post.

Edit: yep - http://docs.libuv.org/en/v1.x/design.html#file-i-o

I can fully believe that there's some cleverness going on with node file I/O - but there should be no meaningful difference in performance between returning the result via a Promise, versus a callback.

It depends - I would assume the callback pattern is much easier to JIT than the promise pattern and requires less objects to be allocated, but you’re right. That’s a huge difference.

You’d need to benchmark another non-io bound function to find how much overhead comes from promises themselves.

Not enough to add 40% overhead to a 1mb file read, I can tell you that much.

It depends. If disks got so fast that function call overhead starts to dominate, then you might see an effect like this. But I have to imagine reading from an SSD is still 1000x slower (at least) than a function invocation in Javascript.

I don't see that basically ever being the case.

The most recent comment is insightful:

"My guess is that the promise version is idling when IO capacity is available due to scheduling? Is it implemented in an event driven way internally, and if it is (for example using epoll) is the epoll event able to interrupt and cause the promise to continue to be evaluated or does it have to wait for the vm to get around to scheduling it again?"

It didn't occur to me that the async promise is rescheduled. That right there is a concern.

The OP also points out buffer concatenation, which is an odd choice. Reading the file into memory in one go should start with an stat and then a single buffer alloc. But that is probably naive.

Network filesystems, compressed filesystems, and of course the ever-dreaded on-access virus scanners on Windows that 'break' one open source project after another. Who knew that opening the same file 10 times is slow? Everybody. Everybody knew that.

Looking at you, svn team.

But these are both non-blocking APIs. readFileSync is the blocking version.

I believe orf is talking about the read(2) syscall, which is blocking.