Is there systematic performance comparison of std::string and c style string?

Discussion in 'C++' started by yu_kuo@sina.com, Aug 11, 2007.

  1. Guest

    Is there any comparison data on perfomance difference between
    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?
    , Aug 11, 2007
    #1
    1. Advertising

  2. Re: Is there systematic performance comparison of std::string andc style string?

    On 2007-08-11 16:10, wrote:
    > Is there any comparison data on perfomance difference between
    > 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?


    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
    =?UTF-8?B?RXJpayBXaWtzdHLDtm0=?=, Aug 11, 2007
    #2
    1. Advertising

  3. Guest

    On Aug 11, 10:19 pm, Erik Wikström <> wrote:
    > On 2007-08-11 16:10, wrote:
    >
    > > Is there any comparison data on perfomance difference between
    > > 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?

    >
    > 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


    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
    , Aug 12, 2007
    #3
  4. Re: Is there systematic performance comparison of std::string andc style string?

    On 2007-08-12 11:35, wrote:
    > On Aug 11, 10:19 pm, Erik Wikström <> wrote:
    >> On 2007-08-11 16:10, wrote:
    >>
    >> > Is there any comparison data on perfomance difference between
    >> > 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?

    >>
    >> 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

    >
    > 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.


    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
    =?ISO-8859-1?Q?Erik_Wikstr=F6m?=, Aug 12, 2007
    #4
  5. Jim Langston Guest

    <> wrote in message
    news:...
    > Is there any comparison data on perfomance difference between
    > 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?


    In my own testing the overhead of std::string .vs. c-style strings was
    measured in microseconds. I.E. very negligable.
    Jim Langston, Aug 13, 2007
    #5
  6. Jim Langston Guest

    "Jim Langston" <> wrote in message
    news:H_Ovi.34$...
    > <> wrote in message
    > news:...
    >> Is there any comparison data on perfomance difference between
    >> 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?

    >
    > 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.
    Jim Langston, Aug 13, 2007
    #6
  7. Jim Langston wrote:
    > "Jim Langston" <> wrote in message
    > news:H_Ovi.34$...
    >> 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?
    Victor Bazarov, Aug 13, 2007
    #7
  8. Jim Langston Guest

    "Victor Bazarov" <> wrote in message
    news:...
    > Jim Langston wrote:
    >> "Jim Langston" <> wrote in message
    >> news:H_Ovi.34$...
    >>> 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.
    Jim Langston, Aug 13, 2007
    #8
  9. James Kanze Guest

    On Aug 13, 4:02 am, "Jim Langston" <> wrote:
    > <> wrote in message


    > news:...


    > > Is there any comparison data on perfomance difference between
    > > 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?


    > In my own testing the overhead of std::string .vs. c-style strings was
    > measured in microseconds. I.E. very negligable.


    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:
    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, Aug 13, 2007
    #9
  10. James Kanze Guest

    On Aug 13, 5:03 am, "Jim Langston" <> wrote:
    > "Victor Bazarov" <> wrote in message


    > news:...


    > > Jim Langston wrote:
    > >> "Jim Langston" <> wrote in message
    > >>news:H_Ovi.34$...
    > >>> 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++.)

    --
    James Kanze (GABI Software) email:
    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, Aug 13, 2007
    #10
  11. Guest

    On Aug 12, 6:58 pm, Erik Wikström <> wrote:
    > On 2007-08-12 11:35, wrote:
    >
    >
    >
    >
    >
    > > On Aug 11, 10:19 pm, Erik Wikström <> wrote:
    > >> On 2007-08-11 16:10, wrote:

    >
    > >> > Is there any comparison data on perfomance difference between
    > >> > 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?

    >
    > >> 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

    >
    > > 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.

    >
    > 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- Hide quoted text -
    >
    > - 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
    , Aug 13, 2007
    #11
  12. On Aug 13, 9:20 am, James Kanze <> wrote:
    > 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.
    tragomaskhalos, Aug 13, 2007
    #12
  13. Re: Is there systematic performance comparison of std::string andc style string?

    Hi!

    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::eek:stringstream for concatenation of multiple strings,
    because the std::string::eek:perator + 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, Aug 13, 2007
    #13
  14. Re: Is there systematic performance comparison of std::string andc style string?

    Hi!

    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
    Frank Birbacher, Aug 13, 2007
    #14
  15. Glyn Davies Guest

    Re: Is there systematic performance comparison of std::string andc style string?

    Frank Birbacher wrote:
    > Hi!
    >
    > 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


    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
    Glyn Davies, Aug 13, 2007
    #15
  16. James Kanze Guest

    On Aug 13, 2:50 pm, Glyn Davies <> 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.

    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.

    --
    James Kanze (GABI Software) email:
    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, Aug 13, 2007
    #16
  17. Glyn Davies Guest

    Re: Is there systematic performance comparison of std::string andc style string?

    James Kanze wrote:
    > On Aug 13, 2:50 pm, Glyn Davies <> 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
    >
    > --
    > James Kanze (GABI Software) email:
    > 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
    >
    Glyn Davies, Aug 13, 2007
    #17
  18. Re: Is there systematic performance comparison of std::string andc style string?

    Hi!

    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::eek:stringstream in case of concatenation. It usually
    performs better than std::string::eek:perator + 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
    Frank Birbacher, Aug 14, 2007
    #18
  19. Jorgen Grahn Guest

    On Mon, 13 Aug 2007 02:05:27 -0700, tragomaskhalos <> wrote:

    > 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!
    Jorgen Grahn, Aug 14, 2007
    #19
  20. Jim Langston Guest

    "James Kanze" <> wrote in message
    news:...
    On Aug 13, 5:03 am, "Jim Langston" <> wrote:
    > "Victor Bazarov" <> wrote in message


    > news:...


    > > Jim Langston wrote:
    > >> "Jim Langston" <> wrote in message
    > >>news:H_Ovi.34$...
    > >>> 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++.)

    =========

    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.
    Jim Langston, Aug 15, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peter Jansson
    Replies:
    5
    Views:
    6,294
    Ivan Vecerina
    Mar 17, 2005
  2. NickName

    systematic file(s) deletion

    NickName, Dec 19, 2006, in forum: Java
    Replies:
    39
    Views:
    1,256
    John Ersatznom
    Jan 15, 2007
  3. Fei Liu
    Replies:
    9
    Views:
    440
  4. Jeffrey Walton
    Replies:
    10
    Views:
    936
    Mathias Gaunard
    Nov 26, 2006
  5. John Regehr

    systematic miscompilation of volatile accesses

    John Regehr, Apr 29, 2008, in forum: C Programming
    Replies:
    0
    Views:
    468
    John Regehr
    Apr 29, 2008
Loading...

Share This Page