Re: C++ programming challenge
On Jun 14, 6:29 pm, Jerry Coffin <jcof...@taeus.com> wrote:
In article <alpine.NEB.1.10.0906141203020.13...@sdf.lonestar.org>,
webmas...@jansson.net says...
[ ... ]
Perhaps a slightly larger change would be worthwhile:
int main(int argc, char **argv) {
static char buffer[20*1024*1024];
Why static? :-)
std::ifstream input(argv[1]);
input.rdbuf()->pubsetbuf(buffer, sizeof(buffer));
input.sync_with_stdio(false);
std::cout << std::accumulate(
std::istream_iterator<char>(input),
std::istream_iterator<char>(),
counter());
return 0;
}
It's hard to guess exactly how much difference those changes
will make, but they might be significant.
The real problem is that they might be very significant on your
system, and actually reduce performance on his, or vice versa.
The real problem is that the tunings which will most affect the
performance will depend on the configuration: the system, but
also the amount of real memory available, etc. So writing code
on our machines which will be timed on his is really stabbing in
the dark. (That's also a bit of what's behind my "why static".
I know why, of course---some machines won't support that much
memory on the stack. But mine will, and so will the machine
he's testing it on. And of course, some machines won't accept a
static variable of that size, either.)
Of course, it's all a bit pointless -- if you're really
processing large files often enough to care about speed, some
non-portable code will usually make a much larger difference
than anything like this.
The point is that any I/O tuning you do is really not portable.
You might be able to improve performance by changing the size of
the buffer, but the optimal size will depend on the
configuration where the program runs. And you might loose.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34