Re: Huge performance bottleneck with cin.read.

[Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>]

> | [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.

I was not sure it could qualify as a regression.
Done.

> | 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?

Done.

> | 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()?

OK, Benjamin suggest the same idea. I do not exactly 
understand how this should work. Does it mean to implement cin.read 
in terms of fread on stdin ???

bkoz@redhat.com said:
> looks like the only performance hit is on cin/cout/cerr. This is to be
>  expected: they are no longer buffered. I'm just relieved that normal
> string/file streams are ok, which is cool. I would actually expect
> stringstreams to be faster than the old memory-based stream
> implementation.

Well, I saw it only on input (and the piece of code I quoted seem to 
support that).

Is this unbuffered behaviour mandated by the standard (I did not find 
any reference to this) ??

Actually, I thought that all but cerr were buffered (cerr being the 
unbuffered version of clog), but that's from my old Stroustrup book.
Apparently, the standard says nothing about that (from it it looks 
like clog and cerr can be exactly the same thing).

There is clearly something beyond what I think I know and what I read.

> One way around this is to acually use sync_with_stdio, providing this
> was  working. I'm working on that now. 

OK, I'll wait. Let me know if I can be of any help.

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

PGP signature