Node: why binding.WriteBuffers is not available from api ?

[bgnx]

fs.write() uses process.binding('fs').writeBuffer call but fs.WriteStream can use process.binding('fs').writeBuffers which is more efficient in case when there are multiple chunks for writing. Is there a reason why passing multiple chunks with usage of writeBuffers this is not available for users from fs api ?

[bengl]

@bgnx process.binding('fs').writeBuffers is used when the internal _writev method is called on fs.WriteStream instances (as is done in stream internals):

https://github.com/nodejs/node/blob/246a6fc1078ae3ef257169847704dd8db4122095/lib/internal/fs/streams.js#L327-L369

(writeBuffers is called on line 335).

The recommended approach when you need to write multiple chunks is to use streams.

[addaleax]

I don’t think it’s a terrible idea to expose this, btw. I’ve thought about that in the past, and couldn’t really find any reasons not to besides that it increases API surface.

[bgnx]

Why WriteStream.prototype._write just uses official fs.write() call but WriteStream.prototype._writev uses internal node api which is not a part of official api? Do you see some inconsistencies here? fs.WriteStram it's top-level abstraction that implements stream interface and uses low level fs.api for reading and writing files except for this _writev method. As result fs.WriteStream has exclusive access to something that can increase performance for writing files and when I want to increase performance of my script or just test speed of writeBuffers call I locked to use fs.WriteStram and can't do it with official low level fs.api

[Trott]

@nodejs/fs @nodejs/streams @ronag Thoughts on exposing this via public API?

[cjihrig]

writev() landed since the time this issue was opened. Is that satisfactory?

[addaleax]

Yeah, I think this issue has been resolved by writev() – it’s basically a public API wrapper for writeBuffers.