This is the mail archive of the
mailing list for the libstdc++ project.
Re: [Patch] Fix libstdc++/11378 (take2) + xsputn optmizations
- From: Nathan Myers <ncm-nospam at cantrip dot org>
- To: libstdc++ at gcc dot gnu dot org
- Date: Mon, 7 Jul 2003 08:47:34 -0700
- Subject: Re: [Patch] Fix libstdc++/11378 (take2) + xsputn optmizations
- References: <07D05A69A3D0C14FAEA60C3ACE8E5564028F5588@nike.hir.is>
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,
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?