Re: libstdc++/2211: Performance regression for cin.read with respect to g++-2.95.2 ?

Re: libstdc++/2211: Performance regression for cin.read with respect to g++-2.95.2 ?

[bkoz]

Synopsis: Performance regression for cin.read with respect to g++-2.95.2 ?

Responsible-Changed-From-To: unassigned->bkoz
Responsible-Changed-By: bkoz
Responsible-Changed-When: Tue Jun 26 17:19:30 2001
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->feedback
State-Changed-By: bkoz
State-Changed-When: Tue Jun 26 17:19:30 2001
State-Changed-Why:
    I'm not quite sure if this is still an issue.
    
    std::ios::sync_with_stdio(false)
    
    will improve output performance.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2211&database=gcc

Re: libstdc++/2211: Performance regression for cin.read with respect to g++-2.95.2 ?

[rodrigc]

Synopsis: Performance regression for cin.read with respect to g++-2.95.2 ?

State-Changed-From-To: feedback->closed
State-Changed-By: rodrigc
State-Changed-When: Sun Jan 27 15:27:40 2002
State-Changed-Why:
    No feedback.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=2211

libstdc++/2211: Performance regression for cin.read with respect to g++-2.95.2 ?

[Theodore.Papadopoulo]

>Number:         2211
>Category:       libstdc++
>Synopsis:       Performance regression for cin.read with respect to g++-2.95.2 ?
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 07 11:26:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Theo Papadopoulo
>Release:        unknown-1.0
>Organization:
>Environment:
g++ mainline from 01/22/2001
Linus redhat 6.2 on x86 (P III)
>Description:
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.

mururoa->ls -l toto
-rw-r--r--   1 papadop  robotvis  1367160 Mar  7 11:38 toto
mururoa->cat toto toto | ./a.out ~/Robotvis++/Libs/Image/tests/images/scully.float.inr
Before ifstream::read: 983970673
After ifstream::read: 983970673
Before cin.read: 983970673
After cin.read: 983970682
Before fread: 983970682
After fread: 983970682

With g++-2.95.2, I get:
mururoa->/usr/local/bin/g++ -g -pg -ftemplate-depth-30 -fPIC -DPIC Test.C
mururoa->cat toto toto | ./a.out ~/Robotvis++/Libs/Image/tests/images/scully.float.inr
Before ifstream::read: 983978303
After ifstream::read: 983978303
Before cin.read: 983978303
After cin.read: 983978303
Before fread: 983978303
After fread: 983978303

[regression 2.95.2 was cin.read(ing) as that as the other ways 
of reading]

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.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="Test.C"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Test.C"

I2luY2x1ZGUgPGlvc3RyZWFtPgojaW5jbHVkZSA8ZnN0cmVhbT4KI2luY2x1ZGUgPHN0ZGlvLmg+
CiNpbmNsdWRlIDx0aW1lLmg+CgppbnQKbWFpbihpbnQgYXJnYyxjaGFyICphcmd2W10pCnsKICAg
IGNvbnN0IHVuc2lnbmVkIGRhdGFfc2l6ZSA9IDEzNjcxNjA7CiAgICBjaGFyIGRhdGFbZGF0YV9z
aXplXTsKCiAgICBzdGQ6Omlmc3RyZWFtIGlmcyhhcmd2WzFdKTsKCiAgICBzdGQ6OmNlcnIgPDwg
IkJlZm9yZSBpZnN0cmVhbTo6cmVhZDogIiA8PCB0aW1lKDApIDw8IHN0ZDo6ZW5kbDsKICAgIGlm
cy5yZWFkKGRhdGEsZGF0YV9zaXplKTsKICAgIHN0ZDo6Y2VyciA8PCAiQWZ0ZXIgaWZzdHJlYW06
OnJlYWQ6ICIgPDwgdGltZSgwKSA8PCBzdGQ6OmVuZGw7CgogICAgc3RkOjpjZXJyIDw8ICJCZWZv
cmUgY2luLnJlYWQ6ICIgPDwgdGltZSgwKSA8PCBzdGQ6OmVuZGw7CiAgICBzdGQ6OmNpbi5yZWFk
KGRhdGEsZGF0YV9zaXplKTsKICAgIHN0ZDo6Y2VyciA8PCAiQWZ0ZXIgY2luLnJlYWQ6ICIgPDwg
dGltZSgwKSA8PCBzdGQ6OmVuZGw7CgogICAgc3RkOjpjZXJyIDw8ICJCZWZvcmUgZnJlYWQ6ICIg
PDwgdGltZSgwKSA8PCBzdGQ6OmVuZGw7CiAgICBmcmVhZChkYXRhLDEsZGF0YV9zaXplLHN0ZGlu
KTsKICAgIHN0ZDo6Y2VyciA8PCAiQWZ0ZXIgZnJlYWQ6ICIgPDwgdGltZSgwKSA8PCBzdGQ6OmVu
ZGw7Cn0K