This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Huge performance bottleneck with cin.read.
- To: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- Subject: Re: Huge performance bottleneck with cin.read.
- From: Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>
- Date: 07 Mar 2001 18:56:16 +0100
- Cc: libstdc++ at gcc dot gnu dot org
- Organization: CMLA, ENS Cachan -- CNRS UMR 8536 (France)
- References: <200103071523.f27FN8Q06455@mururoa.inria.fr>
Theodore Papadopoulo <Theodore.Papadopoulo@sophia.inria.fr> writes:
| [1 <text/plain; us-ascii (7bit)>]
|
| I have a huge performance problem with a call to a libstdc++-v3
| function. istream::read. This is true only for I/O done with cin
| (by the way this is a regression with respect to g++-2.95.2 for two
| reasons, see below)
Then, I'd suggest you fill in a GNATS note.
[...]
| With g++-2.95.2, I get:
|
| mururoa->/usr/local/bin/g++ -g -pg -ftemplate-depth-30 -fPIC -DPIC Test.C
| Test.C: In function `int main(int, char **)':
| Test.C:13: implicit declaration of function `int time(...)'
Please, could fill in a bug-report and mark it as a regression?
[...]
| The crux of the problem seem to be (in fstream.tcc).
|
| // XXX So that istream::getc() will only need to get 1 char,
| // as opposed to BUF_SIZE.
| if (__fd == 0)
| _M_buf_size = 1;
|
| Consequently, characters are read one by one which is extremely
| costly.
|
| Is this absolutely necessary (I cannot find support for this in the
| standard, but my reading has been quick)???
|
| If yes, how can we avoid this behaviour for the read function:
sync_with_stdio()?
-- Gaby