Re: [Patch] Fix libstdc++/11378 (take2) + xsputn optmizations

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Mon, Jul 07, 2003 at 10:08:48AM -0000, P?tur Run?lfsson wrote:
> > +	  // Measurement would reveal the best choice.
> > +	  const size_t __chunk = 1ul << 10;
> > +	  size_t __bufavail = this->epptr() - this->pptr();
> > +
> > +	  // Don't mistake 'uncommitted' mode buffered with unbuffered.
> > +	  if (!_M_writing && this->_M_buf_size > 1)
> > +	    __bufavail = this->_M_buf_size - 1;
> > +
> > +	  const size_t __limit = std::min(__chunk, __bufavail);
> > +	  if (__n >= __limit)
> 
> It seems to me that __limit should always be set to _M_buf_size - 1,
> that way the number of write calls is minimized (IIRC this is what
> libio does).

That this is an optimization is not expected to be obvious.  The clue 
is that above some threshold, a series of block copies followed by a 
system call is more expensive than two system calls without the copies.

As Paolo noted, it remains sub-optimal until after we get filebuf using 
writev(), so that flushing existing characters may be combined with 
writing out the new characters.  A further optimization might be to 
buffer some of the characters at each end, instead of writing them
directly, when it allows us to arrange that the writes might be 
delimited on block boundaries: writes of whole blocks can be much more 
efficient than writes of partial blocks.  At the same time, we can 
allocate the buffer using anonymous mmap; combined with favoring writes 
of whole blocks, that allows filebuf to cooperate wonderfully with 
NetBSD and OpenBSD's UVM, and enable true zero-copy I/O in plausible 
programs.  (Linux might get support for blockwise zero-copy I/O, too, 
someday.)

Of course all these optimizations can be done without breaking the ABI,
so could be done at any time.  Do we all agree that large-file support 
is much more urgent, by that criterion?

Nathan Myers
ncm-nospam@cantrip.org