This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Fix libstdc++/11722


On Tue, Sep 14, 2004 at 05:01:21PM +0200, Paolo Carlini wrote:
> 
> > if (__avail != 0)
> >   {
> >     traits_type::copy(__s, this->gptr(), __avail);
> >     __s += __avail;
> >     this->gbump(__avail);
> >     __ret += __avail;
> >     __n -= __avail;
> >   }
> >
> >This way it doesn't waste time checking __gptr < __egptr again
> >when __avail == 1, and doesn't waste time adding zeroes to __s,
> >__ret, and __n when __avail == 0.  A really smart optimizer 
> >might do part of that transformation, but it seems clearer not 
> >to depend on it.
>
> We have *very* consistent evidence that special casing the single char case
> leads to much better performance (at least with the current optimizers):
> remember the *impressive* improvement we got in basic_string
> 
>    http://gcc.gnu.org/ml/libstdc++/2004-04/msg00096.html

Indeed, somehow I misread *this->gptr() as this->sgetc().

But I do think that the most common case must be __avail == 0, so maybe

  if (__avail != 0)
    {
      if (__avail == 1)
        *__s = *this->gptr();
      else
        traits_type::copy(__s, this->gptr(), __avail);
      __s += __avail;
      this->gbump(__avail);
      __ret += __avail;
      __n -= __avail;
    }

> This leads to the most important source of "uglyness" in the code...
> 
> >We are at least certain that the target __s doesn't overlap the 
> >buffer, so traits_type::copy suffices, and ought to be faster.
>
> This is (even) more subtle: indeed, I wanted to use copy. Then, i
> considered the possibility of a user provided buffer (via setbuf),
> which he can control and access directly. In that case, as a matter of
> QoI, I think we should allow the user to carry out some strange
> tricks, i.e., calling sgetn with a pointer inside his setbuf-ed get
> area. That crazy user expects, I think, the semantics of move.  What
> do you think? Shall we allow that kind of weird code?

No.  When the user hands over a buffer via setbuf, the streambuf owns
it, and the user cannot assume anything about what's in it.  We might
want to document extensions, e.g. guarantees when the buffer is an 
anonymously-mmapped page sequence, but nothing that allows games like 
this.  (For example, there might be advantages to putting characters
at a position in the buffer that matches their position, modulo page
size, in the file.)

Nathan Myers
ncm-nospam@cantrip.org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]