On Thu, 2 Jan 2003 06:49:08 +0000 (UTC), d_cymbal@hotmail.com (Damien
Cymbal) wrote:

>Happy New Year All.

>The real subject of this message really is: "Can MSVC++ 6.0 fstream
>implementation really be this slow?"

There is a bug in MSVC6's library that causes buffering to be
needlessly disabled for files opened by name.

See the <fstream> section here:

http://www.dinkumware.com/vc_fixes.html

For some reason (there were some legal wranglings around Dinkumware's
library IIRC) those fixes never made it into a service pack.

As a workaround, I think you can open files using the constructor,
rather than with the "open" member function. e.g. not:
ofstream ofs;
ofs.open("myfile.txt");
but:
ofstream ofs("myfile.txt");

You can also fix it by upgrading to VC 7 (or better, 7.1) or buy the
upgrade VC6 library from www.dinkumware.com

Tom

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> Anyway, I traced it down to the file i/o.  As a quick hack, I replaced a
> few functions using ifstream.read() with fopen()/fread() just for
> comparison sake and not really expecting much, and performance jumped way
> beyond whatever I expected. As a test, I just wrote a simple app that
> read a file as fast as it could using a 16K buffer, optionally either
> using streams (ios::in|ios::binary) or fread() ("rb").  In all cases, the
> results were not even close.  Finally, I compiled my little test app with
> cygwin GCC 3.2 on the same machine and those stream/C results are much
> more in order of what I expected.
>
> For example sake, reading a 46MB file:
>
> MSVC fread          ~250ms
> MSVC ifstream       ~6550ms
> GCC fread           ~375ms
> GCC ifstream        ~410ms
>
> So, have others also seen this discrepancy?

Yes I have. I don't see how any of the C++ iostream library in your
compilers case could be faster than stdio as it built on top of stdio (a
design decision as it makes it portable).

I can't do any better than referring to the thread "Maximum throughput" on
microsoft.public.vc.stl. See

http://groups.google.com/groups?safe=images&ie=UTF-8&oe=UTF-8&as_ugroup=micr
osoft.public.vc.stl&as_usubject=maximum%20throughput&lr=&hl=en

and read it in its entirety. You might find that

std::ifstream    if;
:
if.rdbuf()->pubsetbuf(NULL, 16384);

helps on doing a successful open (particularly if reading sequentially in
small chunks).

>  It seems crazy to me and I
> keep thinking I must be missing something somewhere. Am I resigned to not
> using streams for file i/o in MSVC 6?  Any first hand experience with
> MSVC 7 as far this being resolved?

That I don't know. I would be interested to find out if the library has
changed.

Stephen Howe


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

[omissis]
> I can't do any better than referring to the thread "Maximum throughput" on
> microsoft.public.vc.stl. See
>
>
http://groups.google.com/groups?safe=images&ie=UTF-8&oe=UTF-8&as_ugroup=micr
> osoft.public.vc.stl&as_usubject=maximum%20throughput&lr=&hl=en
>

As usual, too long links get always broken in more parts ... a best solution
could be generating a link using makeashorterlink.com
The following is the link to the discussion above:
 http://makeashorterlink.com/?G42E21FE2



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

===================================== MODERATOR'S COMMENT:

I approved the initial article by mistake.  I'm approving this response,
since it is a response to something in the newsgroup, but, unless
this discussion drifts to something on-topic, further discussion should
go to another newsgroup.


===================================== END OF MODERATOR'S COMMENT
Damien Cymbal wrote:


> Anyway, I traced it down to the file i/o.  As a quick hack, I replaced a
> few functions using ifstream.read() with fopen()/fread() just for
> comparison sake and not really expecting much, and performance jumped way
> beyond whatever I expected. As a test, I just wrote a simple app that
> read a file as fast as it could using a 16K buffer, optionally either
> using streams (ios::in|ios::binary) or fread() ("rb").  In all cases, the
> results were not even close.  Finally, I compiled my little test app with
> cygwin GCC 3.2 on the same machine and those stream/C results are much
> more in order of what I expected.
>
> For example sake, reading a 46MB file:
>
> MSVC fread          ~250ms
> MSVC ifstream       ~6550ms
> GCC fread           ~375ms
> GCC ifstream        ~410ms

Have you tried compiling with optimizations turned on/debug turned off?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 2 Jan 2003 06:49:08 +0000 (UTC), d_cymbal@hotmail.com (Damien
Cymbal) wrote:

>Happy New Year All.
>
>This is probably more implementation specific than I should be posting
>here, but I'm hoping to garner a little bit more well-rounded feedback
>then if I just post to the ms-specific groups.
>
>The real subject of this message really is: "Can MSVC++ 6.0 fstream
>implementation really be this slow?"
>
>I was experiencing dreadful performance with an app (in fact the Java
>prototype was running faster than the C++ version, talk about wanting to
>hide under a rock....)
>
>Anyway, I traced it down to the file i/o.  As a quick hack, I replaced a
>few functions using ifstream.read() with fopen()/fread() just for
>comparison sake and not really expecting much, and performance jumped way
>beyond whatever I expected. As a test, I just wrote a simple app that
>read a file as fast as it could using a 16K buffer, optionally either
>using streams (ios::in|ios::binary) or fread() ("rb").  In all cases, the
>results were not even close.  Finally, I compiled my little test app with
>cygwin GCC 3.2 on the same machine and those stream/C results are much
>more in order of what I expected.
>
>For example sake, reading a 46MB file:
>
>MSVC fread          ~250ms
>MSVC ifstream       ~6550ms
>GCC fread           ~375ms
>GCC ifstream        ~410ms
>
>So, have others also seen this discrepancy?

Yes, and I've seen much worse in my measurements. I no longer use
streams for anything but test code, because for the compilers I have to
use streams are intolerably slow. Can't say I miss streams much, though.

--
Be seeing you.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Happy New Year All.

This is probably more implementation specific than I should be posting
here, but I'm hoping to garner a little bit more well-rounded feedback
then if I just post to the ms-specific groups.

The real subject of this message really is: "Can MSVC++ 6.0 fstream
implementation really be this slow?"

I was experiencing dreadful performance with an app (in fact the Java
prototype was running faster than the C++ version, talk about wanting to
hide under a rock....)

Anyway, I traced it down to the file i/o.  As a quick hack, I replaced a
few functions using ifstream.read() with fopen()/fread() just for
comparison sake and not really expecting much, and performance jumped way
beyond whatever I expected. As a test, I just wrote a simple app that
read a file as fast as it could using a 16K buffer, optionally either
using streams (ios::in|ios::binary) or fread() ("rb").  In all cases, the
results were not even close.  Finally, I compiled my little test app with
cygwin GCC 3.2 on the same machine and those stream/C results are much
more in order of what I expected.

For example sake, reading a 46MB file:

MSVC fread          ~250ms
MSVC ifstream       ~6550ms
GCC fread           ~375ms
GCC ifstream        ~410ms

So, have others also seen this discrepancy?  It seems crazy to me and I
keep thinking I must be missing something somewhere. Am I resigned to not
using streams for file i/o in MSVC 6?  Any first hand experience with
MSVC 7 as far this being resolved?

dc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]