Re: What is the output of this program?
Alf P. Steinbach wrote:
* James Kanze:
Alf P. Steinbach wrote:
* kanze:
Earl Purple wrote:
Alf P. Steinbach wrote:
push_back can be a tad inefficient on strings, because
strings are usually short, and for short sequences the
reallocations, assuming scaling of buffer size, are more
frequent and thus more costly.
I don't think it's the allocations that make push_back
inefficient, (you can do reserve() ahead and std::string
will often allocate enough anyway). What makes it
inefficient is that push_back has to do a bounds-check on
every call (how else will it know whether to reallocate?).
Much more efficient is resize().
I doubt it. I also doubt that either make a significant
difference.
Possibly you're talking about something entirely different
than the following program?
[snip]
point where even if one version were ten times faster than the
other, I can't see it making significant difference in an actual
program.
Oh, come on. One order of magnitude is significant.
One order of magnitude in the execution time of the complete
application is significant. Whether it takes me a milliseconde
or 10 millisecondes to format a message that I output only a
couple of times a minute (or less) is not significant. And in
an awful lot of programs, the only thing you're doing with
std::string is formatting output messages (which aren't that
frequent) or parsing the configuration file (once on start up).
There are times when the performance of std::string will matter.
There are probably even a few cases where a 10% difference is
important. If my experience is typical, however, they aren't
very common. (And to get back to the original theme: you don't
just use resize() because you think it is faster. You measure
the actual implementation you are using, on the hardware you are
using.)
Except if the application is such that you can throw hardware
at the problem (OK for in-house server app I guess, but not
for something shipped to users), where said hardware might be
much cheaper than programmer's time.
Even for in-house applications, there are often limits to
"throwing hardware at it" (even in cases where it is the
cheapest solution). I've had to optimize code more than once,
even when the program would only run on a single machine.
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]