What influences C++ I/O performance?

[SzH]

I would like to read in large integer matrices from text files, as
quickly as possible. I did a naive implementation (see below), but
for an input file with 100 rows and 250000 columns it runs more than
5x slower when compiled with visual studio express 2008 than the
version compiled with gcc 4.2.1 (mingw), on the same computer, same
OS.

I am not a regular C++ user. What are the things (relevant to the
standard C++ library) that influence the performance of I/O? I don't
believe that this is a "bug" in the VS compiler. It is more likely
that there are some relevant settings for iostreams (with a
significant impact on performance) that I am not aware of.

Any suggestions for making this program perform well portably would me
most welcome!

This is the relevant portion of the code:

std::ios::sync_with_stdio(false);
std::ifstream infile(path);

input_array arr(); // see note below

int row = 0, max_col = 0;

std::string line;
while (std::getline(infile, line)) {
std::istringstream ln(line);
int number;
int col = 0;
while (ln >number) {
arr.append(number);
col++;
}
if (col != 0) {
if (row == 0)
max_col = col;
if (col != max_col) {
/*
* Array is not rectangular.
* Handle error (exit).
*/
}
row++;
}
}

Notes: 'input_array' is just a simple integer array, which grows
exponentially to accommodate new elements. It is not the source of
the performance problem.

Szabolcs

[Krice]

On 3 helmi, 16:04, SzH <[e-mail]:

I am not a regular C++ user. What are the things (relevant to the
standard C++ library) that influence the performance of I/O?

Compiler optimization settings could be worth trying.
I guess VS has slower debug mode executables as well.

[SzH]

On Feb 3, 5:09 pm, Krice <[e-mail]:

On 3 helmi, 16:04, SzH <[e-mail]:

I am not a regular C++ user. What are the things (relevant to the
standard C++ library) that influence the performance of I/O?

Compiler optimization settings could be worth trying.
I guess VS has slower debug mode executables as well.

I forgot to mention that "release" mode was used with VS
(optimizations turned on). In "debug" mode, the program is twice as
slow, i.e. 10x as slow as with gcc. Whether optimizations are turned
on or not didn't really matter with gcc.

The VS timing was approx 80 seconds (in "release" mode), while the gcc
timing was about 15 seconds.

[Roland Pibinger]

On Sun, 17 Feb 2008 05:05:47 -0800 (PST), SzH wrote:

>How do I read the numbers without the istringstream? But
std::istringstream isn't the source of the "slowness" anyway. The
piece that takes a long time to execute is

while (ln >number)
col++;

This sentence seems to contain a contradiction. Anyway. AFAICS, you
have a string of ints separated by some whitespace. You could try
something like the following to extract the ints (no predicitons about
performance are provided). Error handling is omitted like in the
original code.

int main() {
using namespace std;

string str = "1 314 1024 ";

char* current = const_cast<char*(str.c_str()) ;

while(true) {
const char* start = current;
long result = strtol(start, &current, 0);
if(start == current) {
break;
}
cout << result << " ";
}
}
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[SzH]

On Feb 17, 5:06 pm, [e-mail] (Roland Pibinger) wrote:

On Sun, 17 Feb 2008 05:05:47 -0800 (PST), SzH wrote:

How do I read the numbers without the istringstream? But
std::istringstream isn't the source of the "slowness" anyway. The
piece that takes a long time to execute is

while (ln >number)
col++;

This sentence seems to contain a contradiction.

Yes. I should have said that *constructing* the istringstream is not
the problem.

Anyway. AFAICS, you
have a string of ints separated by some whitespace. You could try
something like the following to extract the ints (no predicitons about
performance are provided).

That would be hard to do with these unpredictable libraries ... but
fortunately it is a lot faster :) Thanks!

Timings are

vs: 10.531
gcc: 4.953

compared to the previous

vs: 51.165
gcc: 8.795

Error handling is omitted like in the
original code.

int main() {
using namespace std;

string str = "1 314 1024 ";

char* current = const_cast<char*(str.c_str()) ;

while(true) {
const char* start = current;
long result = strtol(start, &current, 0);
if(start == current) {
break;
}
cout << result << " ";
}

}

--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Jerry Coffin]

In article <98cd0ba4-cfc5-4052-8a09-07b7d1b6a7da@
41g2000hsc.googlegroups.com>, sz******@gmail.com says...

[ ... ]

Yes, that's the very disappointing thing about C++. One can never
rely on the damn standard library for good performance! You just
switch compilers, and suddenly find that a stupid scripting language
performs much better than your C++ program.

In this case, it's really a matter of the nature of templates -- since
their behavior can change substantially when instantiated over a
different type, it's not really possible to pre-compile a template to
object code.

That means if you use standard library (or almost any other) code that's
based on templates (which includes most of the C++ standard library),
all that code is being compiled as part of your program. When, as in
your case, you use a compiler from which nearly all optimization
capability has been removed, the result can (obviously) be pretty ugly.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-02-17 19:48, Jerry Coffin wrote:

In article <0ab81bd1-1e5a-43eb-8a7f-bfc9d0148d5c@
28g2000hsw.googlegroups.com>, sz******@gmail.com says...

[ ... ]

1) the newer version of VC++ has reduced I/O speed a lot.

I only have VS 2008 Express, so I don't know, but it seems possible.

If you previously said you were using the "Express" edition, I didn't
catch it.

In any case, that's almost certainly the majority of the explanation
right there. Much of what they do in the Express edition of the compiler
is disable nearly _all_ optimization. Since iostreams are templates,
that means most of the code involved is being compiled with virtually no
optimization applied.

Fortunately, this is fairly easy to fix: the full version of the
compiler is included with (among other things) a number of versions of
the Windows SDK. If you care about performance at all, I'd advise
downloading and using that (at least for final builds).

IOW, I suspect (quite strongly) that the difference we're seeing IS
between different version of the compiler; the difference between 7.1
and 8.0 or 9.0 is probably NOT significant, but the difference between
the full, optimizing version of the compiler and the "Express" version
probably is.

Actually the compiler in the Express editions are exactly the same as in
the other editions, the differences are the libraries (MFC etc.) and
tools that are included. Perhaps there are some differences in the flags
that are used by default but that is easily fixed.

--
Erik Wikström

[=?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=]

On 2008-02-17 19:48, Jerry Coffin wrote:

In article <0ab81bd1-1e5a-43eb-8a7f-bfc9d0148d5c@
28g2000hsw.googlegroups.com>, sz******@gmail.com says...

[ ... ]

1) the newer version of VC++ has reduced I/O speed a lot.

I only have VS 2008 Express, so I don't know, but it seems possible.

If you previously said you were using the "Express" edition, I didn't
catch it.

In any case, that's almost certainly the majority of the explanation
right there. Much of what they do in the Express edition of the compiler
is disable nearly _all_ optimization. Since iostreams are templates,
that means most of the code involved is being compiled with virtually no
optimization applied.

Fortunately, this is fairly easy to fix: the full version of the
compiler is included with (among other things) a number of versions of
the Windows SDK. If you care about performance at all, I'd advise
downloading and using that (at least for final builds).

I forgot to add, the Windows Platform SDK comes as a part of Visual C++
2008 Express, so downloading it again will buy you nothing.

--
Erik Wikström

[Jerry Coffin]

In article <ff5e51c0-c004-43bd-9c02-ef6ef7d6a098
@p73g2000hsd.googlegroups.com>, sz******@gmail.com says...

[ ... ]

You know, it's just terribly disappointing and frustrating when one
finds out that even a stupid scripting language outperforms one's C++
implementation.

I'd be rather happy with that. Scripting languages tend to make
development and maintenance cheap and easy, so when they can do the job,
it's a great thing.

Most scripting languages are (at least partially) interpreted, so
execution speed tends to depend heavily upon the amount of code that
needs to be executed. When/if you can get the job done in only a line or
two of code, they'll typically be as fast as (and perhaps faster than)
anything you can reasonably write yourself. In particular, the code that
implements those few lines of code is likely to be used enough to
justify spending quite a bit of time and effort on optimizing them.

Chances are that when you recreate that functionality on your own that
you can't justify spending nearly as much time and effort on optimizing
this code, so you may not get a lot faster result.

--
Later,
Jerry.

The universe is a figment of its own imagination.