This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] Step2: don't use _M_out_lim in filebuf, have filebuf non unified, etc...
On Tue, Jun 24, 2003 at 11:13:05PM +0200, Paolo Carlini wrote:
> Thanks Nathan. I can reproduce you results here, with my P4. Therefore I
> would be tempted to move right away sputc, sbumpc (and also, perhaps,
> sungetc and sputbackc).
I moved all four, and that's what I would recommend.
> An additional puzzling data point, however: have you tried moving _only_
> sbumpc to std_streambuf.h vs moving both sbumpc and sputc?
>
> Here, if both are moved 9876 regresses to the pre-patch performance...
That seems impossible. The 9876 test case only exercises sputc.
I'm about to study the .s to see what streambuf does differently in
that loop than glibc's stdio. It seems odd to be faster on sputc
vs. putc, but slower on sgetc vs. getc.
Nathan Myers
ncm-nospam@cantrip.org
- References:
- [Patch] Step2: don't use _M_out_lim in filebuf, have filebuf nonunified, etc...
- Re: [Patch] Step2: don't use _M_out_lim in filebuf, have filebuf non unified, etc...
- Re: [Patch] Step2: don't use _M_out_lim in filebuf, have filebufnon unified, etc...
- Re: [Patch] Step2: don't use _M_out_lim in filebuf, have filebuf non unified, etc...
- Re: [Patch] Step2: don't use _M_out_lim in filebuf, have filebufnon unified, etc...