fist i thought D in Nathans version. this or may be this approach (it's
cork modified in fact):
s.write('first') // writes immediately 'first'
s.buffer('second') // nothing written
s.buffer('third') // nothing written
s.write('forth') // writes 'secondthirdforth', so it flushes previously
buffered data
s.buffer('fifth') // nothing written
s.buffer('sixth') // nothing written
s.end() // writes 'fithsixth' and emits 'end' etc.
s.buffer has same signature as s.write, handles watermarks etc. it just
holds an array of buffers internally. i think it inherits upsides of
version B but not it's downsides (only one function, write/end
flushes/uncorks, so you will uncork, at last on .end()). But i don't know
if it's easy to implement or not.
Am Dienstag, 23. April 2013 09:44:54 UTC+2 schrieb Ben Noordhuis:
>
> On Tue, Apr 23, 2013 at 4:15 AM, Mikeal Rogers
> <[email protected]<javascript:>>
> wrote:
> > Is there a reason not to just have the underlying libuv *always* writev
> when it has more than one pending buffer to write?
>
> It could but it doesn't (at least, not always.) On most operating
> systems, it's often faster to call write() two or three times in a row
> than it is to call writev() once (for small payloads.)
>
> There is an open issue[1] and some in-progress work[2] but it only has
> a significant impact on big writes, on the order of 100 kB or more.
>
> [1] https://github.com/joyent/libuv/issues/742
> [2] https://github.com/bnoordhuis/libuv/compare/issue742
>
> > I'm wondering whey we can't just optimize this behind the scenes, is
> there a reason we need to map each stream write a write syscall?
>
> node.js and libuv optimize for latency first, throughput second
> (because you can always buffer higher up in the application.) IOW, it
> tries to send out pending data as quickly as possible.
>
> (Caveat emptor: I'm not 100% sure if that statement is always correct
> when streams2 are involved.)
>
> Because node.js doesn't know when new data will be sent, it doesn't
> know when it's sound to buffer. That's why the choice to buffer has
> to be an explicit one, made by the programmer.
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
