Is there systematic performance comparison of std::string and c style string?
yu_...@sina.com
std::string and c style string? Or maybe if there are source code
which could be used to measuer on different compiler/platform, in a
systematic way?
Erik Wikström
Most certainly there is, google is your friend. I believe if you include
the word rope in the search you'll find some. Remember though that all
the benchmarks in the world does not mean shit if they don't measure
what you need, so instead of looking for other peoples benchmarks
perform your own with the code you need to run.
--
Erik Wikström
yu_...@sina.com
Thanks for your reply and suggestion. Actually I myself am prety
convinced to prefer std::string, but it's simply not a common sense of
my colleagues. That's why I'm searching for hard proofs to convince
people. I did googled for some time, but didn't find what I can
directly use. Any way I could write some code to compare functionality
we are interested, just as you have suggested.
Regards,
Kevin
Erik Wikström
I might have miss understood you original question a bit, I thought that
you wanted to know which was the best performer for a certain kind of
use (such as really large amounts of strings or really large strings) in
which case there might sometimes be some benefits to using C-strings.
But if you mean usage of std::string vs. C-strings in general then I'm
very hard pressed to come up with any argument in favour of C-strings
but it's quite easy to find arguments for std::string (ease of use, no
risk of overflows, don't have to allocate memory manually etc.). In fact
one very good argument against using C-strings is that most buffer
overflow attacks are caused by improper usage of C-strings, and if
std::string had been used instead the code would have been much simpler
and more safe. As for speed, I'd say that std::string is fast enough for
most usages and if your application is an exception you'd probably know
it due to profiling and benchmarks you've already done.
--
Erik Wikström
Jim Langston
news:1186841430.6...@g12g2000prg.googlegroups.com...
In my own testing the overhead of std::string .vs. c-style strings was
measured in microseconds. I.E. very negligable.
Jim Langston
news:H_Ovi.34$665...@newsfe04.lga...
Wait,not micro, the one that is smaller than nano. Lets see, mili, micro,
nano, ... umm.. dang.
Victor Bazarov
> "Jim Langston" <tazm...@rocketmail.com> wrote in message
> news:H_Ovi.34$665...@newsfe04.lga...
>> was measured in microseconds. I.E. very negligable.
>
> Wait,not micro, the one that is smaller than nano. Lets see, mili,
> micro, nano, ... umm.. dang.
Pico? Atto? Femto?
Jim Langston
news:8JydnTuOLfB1WyLb...@comcast.com...
Pico, that's it. It took about 4 pico seconds longer to allocate a
std::string than to use a c-style array in my testing. Negligable for any
application.
James Kanze
> news:1186841430.6...@g12g2000prg.googlegroups.com...
My own testing found several orders of magnitude. Developing
something using C style strings might take a week, where with
std::string, it would be a couple of hours.
--
James Kanze (GABI Software) email:james...@gmail.com
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
James Kanze
> "Victor Bazarov" <v.Abaza...@comAcast.net> wrote in message
> news:8JydnTuOLfB1WyLb...@comcast.com...
> > Jim Langston wrote:
> >> "Jim Langston" <tazmas...@rocketmail.com> wrote in message
> >>news:H_Ovi.34$665...@newsfe04.lga...
> >>> In my own testing the overhead of std::string .vs. c-style strings
> >>> was measured in microseconds. I.E. very negligable.
> >> Wait,not micro, the one that is smaller than nano. Lets see, mili,
> >> micro, nano, ... umm.. dang.
> > Pico? Atto? Femto?
> Pico, that's it. It took about 4 pico seconds longer to
> allocate a std::string than to use a c-style array in my
> testing. Negligable for any application.
Picosecond differences are probably less than the resolution of
your measurement system; it would be more accurate to say that
you found no measurable difference. But that still doesn't tell
us anything, because we don't know what you were measuring.
Note too that for any given activity, the implementation of
std::string can make a significant difference. For some things,
the implementation in g++ is significantly faster than that in
VC++, for others, the reverse is true. (G++ uses reference
counting; VC++ deep copy with the small string optimization. If
you don't copy much, and most of your strings are short, VC++
will be faster; if you copy long strings a lot, g++.)
yu_...@sina.com
>
> - Show quoted text -
Actually we are dealing with telecomunication protocols, like SIP and
Diameter. Most contents are now text based, so we are right dealing
with large amount of strings, and sometimes the string can be large
(To about Mega bytes). Most operation on string would be copy, find
and concatecation, very little modify or replace operation.
And std::string haven't been widely used yet, so I can't just change
it overnight. That's why I have to do some work outside our
application, and the analysis should better cover as much operations
on strings of different length. That's not a very simple work to do,
I'm just lazy and wonder if somebody had done that.
Regards,
Kevin
tragomaskhalos
> Note too that for any given activity, the implementation of
> std::string can make a significant difference. For some things,
> the implementation in g++ is significantly faster than that in
> VC++, for others, the reverse is true. (G++ uses reference
> counting; VC++ deep copy with the small string optimization. If
> you don't copy much, and most of your strings are short, VC++
> will be faster; if you copy long strings a lot, g++.)
>
I've also noticed a lot of code out there where people
do this:
void foo(std::string s) { ... }
where they could be doing this instead:
void foo(const std::string& s) { ... }
Presumably this is a Java / C# influence, but appied
systematically across a codebase with a "copying
std::string" library, this is going to involve a lot
of extra copying for zero benefit, which I suspect
cannot be optimised away in the general case. I
wonder how many "performance problems" reported
with std::string could be eliminated by correcting
this usage.
I think it's "More Exceptional C++" by Herb Sutter
that has an appendix comparing different types of
string implementation strategy, including problems
with some implementations of reference counting.
Frank Birbacher
yu_...@sina.com schrieb:
> Actually we are dealing with telecomunication protocols, like SIP and
> Diameter. Most contents are now text based, so we are right dealing
> with large amount of strings, and sometimes the string can be large
> (To about Mega bytes). Most operation on string would be copy, find
> and concatecation, very little modify or replace operation.
Try using std::ostringstream for concatenation of multiple strings,
because the std::string::operator + will not allocate more memory than
is necessary to hold just the two operands. That is, compare:
s1 + s2 + s3 + " WHERE " + s4 + s5
with:
stream << s1 << s2 << s3 << " WHERE " << s4 << s5;
which may be faster. (AFAIK, Java is doing such a conversion from
operator + to streams (StringBuffer in Java) automatically when compiling.)
Frank
Frank Birbacher
James Kanze schrieb:
> My own testing found several orders of magnitude. Developing
> something using C style strings might take a week, where with
> std::string, it would be a couple of hours.
Good point! I like that. :D
Frank
Glyn Davies
Better suggestion is to develop with std::string initially, then
optimise where necessary. (Rational Quantify is a great tool!)
On one project by switching to stack based 'C' strings in some inner
loops I managed to knock 50% off the application startup.
Another thing to do is reserve() at least a good apromixation of the
final string. Biggest speed difference with C/vs std::string is down
to the memory allocation / free-ing.
Just my 2p
Glyn
James Kanze
> Frank Birbacher wrote:
> > James Kanze schrieb:
> >> My own testing found several orders of magnitude. Developing
> >> something using C style strings might take a week, where with
> >> std::string, it would be a couple of hours.
> > Good point! I like that. :D
> Better suggestion is to develop with std::string initially, then
> optimise where necessary. (Rational Quantify is a great tool!)
I'm tempted to say: that has nothing to do with std::string. In
general, write clean, understandable code, with rigorous
encapsulation. Then, if it's not fast enough, use the profiler
to see where the problem is, and correct only that.
Note that the most important single aspect for performance
critical code is encapsulation. Because without good
encapsultation, trying to change anything, once you've found the
problem, can be hell.
> On one project by switching to stack based 'C' strings in some
> inner loops I managed to knock 50% off the application
> startup.
Possibly changing to a different std::string implementation
could have had a similar effect; a lot depends on what you are
doing. Or, if you have a fixed upper limit to the length you
need, create your own fixed length strings. (A lot of
applications, like those I currently work on, write their data
to a data base. If the field in the data base is varchar(20),
then a fixed length string of length 20 is more appropriate than
std::string. And in fact, our current implementation does use
FixedString... a template on the actual length.)
> Another thing to do is reserve() at least a good apromixation of the
> final string. Biggest speed difference with C/vs std::string is down
> to the memory allocation / free-ing.
Again, it depends. If most of youre strings are short, and the
implementation you are using uses the small string optimization,
you may never have a dynamic allocation/free. Typically, I
suspect that you're right in a lot of cases. But I wouldn't
assume so until I'd actually profiled it.
Glyn Davies
> On Aug 13, 2:50 pm, Glyn Davies <sgd.w...@googlemail.com> wrote:
>> Frank Birbacher wrote:
>
>>> James Kanze schrieb:
>>>> My own testing found several orders of magnitude. Developing
>>>> something using C style strings might take a week, where with
>>>> std::string, it would be a couple of hours.
>
>>> Good point! I like that. :D
>
>> Better suggestion is to develop with std::string initially, then
>> optimise where necessary. (Rational Quantify is a great tool!)
>
> I'm tempted to say: that has nothing to do with std::string. In
> general, write clean, understandable code, with rigorous
> encapsulation. Then, if it's not fast enough, use the profiler
> to see where the problem is, and correct only that.
Probably - I guess I've strayed away from the string argument to more
general territory. My only excuse is that the app we are talking about,
and the app I was working on back then did a lot of string manipulation
(many megabytes of XML munging)
> Note that the most important single aspect for performance
> critical code is encapsulation. Because without good
> encapsultation, trying to change anything, once you've found the
> problem, can be hell.
I'd go with Keep It Simple Stupid, and having a good overall design.
Encapsulation can help, but as with all these things there is no
panacea.
>
>> On one project by switching to stack based 'C' strings in some
>> inner loops I managed to knock 50% off the application
>> startup.
>
> Possibly changing to a different std::string implementation
> could have had a similar effect; a lot depends on what you are
> doing. Or, if you have a fixed upper limit to the length you
> need, create your own fixed length strings. (A lot of
> applications, like those I currently work on, write their data
> to a data base. If the field in the data base is varchar(20),
> then a fixed length string of length 20 is more appropriate than
> std::string. And in fact, our current implementation does use
> FixedString... a template on the actual length.)
Yep, agreed. A good plan.
>
>> Another thing to do is reserve() at least a good apromixation of the
>> final string. Biggest speed difference with C/vs std::string is down
>> to the memory allocation / free-ing.
>
> Again, it depends. If most of youre strings are short, and the
> implementation you are using uses the small string optimization,
> you may never have a dynamic allocation/free. Typically, I
> suspect that you're right in a lot of cases. But I wouldn't
> assume so until I'd actually profiled it.
What we found (only after profiling) was that the small string
functionality was just too small. We could have looked at other STL
implementations (I think we did briefly.) But this was all cross
platform anyway, so a simple cross platform solution was a winner.
Personally I always just use std::string, with judicious use of & and
const. I'll only go back to it if there is a performance issue that
needs addressing.
The reserve issue I mentioned above came in where there was a lot of
string concatenation going on. A quick check of lengths + a reserve
stopped a lot of churn, and improved performance no end.
Cheers,
Glyn
Frank Birbacher
Glyn Davies schrieb:
> The reserve issue I mentioned above came in where there was a lot of
> string concatenation going on. A quick check of lengths + a reserve
> stopped a lot of churn, and improved performance no end.
I'm using std::ostringstream in case of concatenation. It usually
performs better than std::string::operator + when you can't do a resize
because the length is unknown. And you can also to formatting. I'm
actually using this to construct SQL statements with filled in values
like ints.
Frank
Jorgen Grahn
> I've also noticed a lot of code out there where people
> do this:
> void foo(std::string s) { ... }
>
> where they could be doing this instead:
> void foo(const std::string& s) { ... }
>
> Presumably this is a Java / C# influence
Oh yes. I have battled one Java developer who did this on a regular
basis (in C++).
It's ironic, since those languages are all about passing references ...
> but appied
> systematically across a codebase with a "copying
> std::string" library, this is going to involve a lot
> of extra copying for zero benefit, which I suspect
> cannot be optimised away in the general case. I
> wonder how many "performance problems" reported
> with std::string could be eliminated by correcting
> this usage.
If they do it to std::string, they probably do it to all kinds of
objects, and strings become their smallest problem ...
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
Jim Langston
news:1186993213.4...@k79g2000hse.googlegroups.com...
> news:8JydnTuOLfB1WyLb...@comcast.com...
> > Pico? Atto? Femto?
=========
Yes, I had to measure doing it a few million times to tell the difference
between a c-style string and std::string. And results can be thrown off
depending on how the compiler decides to optimize the code. But I was able
to get a difference of around 4 pico seconds using std::string than a
c-style string when I averaged the results. And I found it negligable.
I did this to show someone who was insistant on using c-style strings than
std::strings because he thought std::strings were slower. Showing him the
code and results he agreed that std::strings were usable.
yu_...@sina.com
Regards,
Kevin
Alex Vinokur
Look at C/C++ Program Perfometer
http://sourceforge.net/projects/cpp-perfometer/
http://groups.google.com/group/perfo
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn