5 ms·

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

• orf 6y ago
  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.
  • beaconstudios 6y ago
    Not enough to add 40% overhead to a 1mb file read, I can tell you that much.
    • javajosh 6y ago
      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.
      • beaconstudios 6y ago
        I don't see that basically ever being the case.
• SavantIdiot 6y ago
  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.