slow std::string?

This is a discussion on slow std::string? within the C++ Programming forums, part of the General Programming Boards category; Hey guys, I'm just bored sitting in a comp apps class, and I thought of something (just a passing curiosity). ...

  1. #1
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879

    Question slow std::string?

    Hey guys, I'm just bored sitting in a comp apps class, and I thought of something (just a passing curiosity). Are std::string's very slow compared to simple char*'s?
    Code:
    std::string str = "String";
    int res = strcmp(str.c_str(), "ABCD");
    
    char* str2[] = "String";  //Much faster, or neglible?
    int res2 = strcmp(str2, "ABCD");
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  2. #2
    Confused Magos's Avatar
    Join Date
    Sep 2001
    Location
    Sweden
    Posts
    3,145
    Since it's a class instead of a base type - Yes, they are slower.
    MagosX.com

    Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime.

  3. #3
    Hardware Engineer
    Join Date
    Sep 2001
    Posts
    1,398
    Hey, why don't you make a loop and see how many times each of these executes in... say... one second?

  4. #4
    cgoat
    Guest
    Only the initialization you gave will be different:

    std::string str = "String"; // Allocates storage and copies the data

    char* str2 = "String"; // Just sets the pointer

    Obviously, the copy takes longer.

    Calling c_str() for strcmp has one slight extra thing where it terminates the string before returning the pointer. It's negligible. However, you should really just do str == "ABCD" to test it.

    One advantage to the string class is that it usually uses reference counting, so doing s1 = s2 with the string class does not require a copy until one of them is changed, whereas a strcpy(s1, s2) with char* would do the copy.

  5. #5
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Heh, Magos, I sort of knew that already (I'm not COMPLETELY new to c++...). But, I actually meant are they *much* slower, as in 2X, 3X, 4X, 100X more time needed? Heh, but I guess I'll just give DougDbug's suggestion a shot, I should be able to come up with a few numbers of my own that way.

    Also, cgoat, thanks for the tips. I passed str.c_str() as an argument to a function (not strcmp() in the actual program), though, so... watever But I never knew about the reference counting, thanks for pointing that out
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  6. #6
    Open to suggestions Brighteyes's Avatar
    Join Date
    Mar 2003
    Posts
    204
    >But, I actually meant are they *much* slower, as in 2X, 3X, 4X, 100X more time needed?
    If std::string weren't fast enough to compete with manual C strings then why would everyone use them? Unless your compiler is truly old and has an awful string implementation, you'll find that std::string is as fast or faster than your own C strings due to reference counting and optimized operations.
    p.s. What the alphabet would look like without q and r.

  7. #7
    Confused Magos's Avatar
    Join Date
    Sep 2001
    Location
    Sweden
    Posts
    3,145
    Originally posted by Brighteyes
    If std::string weren't fast enough to compete with manual C strings then why would everyone use them?
    Simpliness! Ask yourself this, why do people use Visual basic instead of C? Because it's faster? Or at least as fast? Hah!
    MagosX.com

    Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime.

  8. #8
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Hmm, so std::string's are slower, not by too much, but easier to use. So would the speed gain be worth the un-readability and trouble of changing every std::string in a program to using c strings instead? Or is it a matter of how they're used and with what frequency they are used?
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  9. #9
    Open to suggestions Brighteyes's Avatar
    Join Date
    Mar 2003
    Posts
    204
    >Simpliness! Ask yourself this, why do people use Visual basic instead of C? Because it's faster? Or at least as fast? Hah!
    Your example doesn't make sense. Visual Basic wasn't designed to compete with C in speed, so one shouldn't expect it to. C++, on the other hand, has maintained at most a 5% difference in performance when compared to C. This was one of the highest priority goals in the design of C++. std::string was designed to replace error prone and difficult to use dynamic C strings. Of course this is faster than using std::string:
    Code:
    char* p = "Some string";
    It's a simple pointer assignment, but if you start out with a pointer and intend to use new/delete with it and resize the strings it contains before you're done then you'll find it difficult to beat std::string in performance.

    >So would the speed gain be worth the un-readability and trouble of changing every std::string in a program to using c strings instead?
    Probably not. You want your code to be as simple as possible. If it turns out to be a performance bottleneck later on you can optimize as needed.
    p.s. What the alphabet would look like without q and r.

  10. #10
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Hmm, then in that case, it would seem that it is something like visual basic vs. c++, except that it is very much closer in speed. Strings are easier to use, but c-strings have the potential, if properly and painstakingly used, to be faster and more powerful Yes, the analogy still stands, although it doesn't really matter at this point to me. I'm too lazy to use c strings anyways
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  11. #11
    Registered User
    Join Date
    Feb 2003
    Posts
    28
    Originally posted by Hunter2
    Hmm, then in that case, it would seem that it is something like visual basic vs. c++, except that it is very much closer in speed. Strings are easier to use, but c-strings have the potential, if properly and painstakingly used, to be faster and more powerful Yes, the analogy still stands, although it doesn't really matter at this point to me. I'm too lazy to use c strings anyways
    Greetings,

    c-strings faster than std::string? I doub't it, std::strings will often be as fast as c-strings and in some circumstances even faster. They become less efficient when frequent reallocations occur, but carefully planning and using std::string properly can help eliminate these instances.
    c-strings more powerfull than std::strings? Not a chance!

  12. #12
    Carnivore ('-'v) Hunter2's Avatar
    Join Date
    May 2002
    Posts
    2,879
    Hmm, well, in this case:
    Code:
    struct bunchOfParams
    {
         //lots of other stuff
    #ifdef CHARSTAR
         char* promptString;
    #else
         std::string promptString;
    #endif
    };
    
    void function2(const char* str)
    {
         //do stuff with str
    }
    
    void function(bunchOfParams bop)
    {
    #ifdef CHARSTAR
         function2(bop.promptString);
    #else
         function2(bop.promptString.c_str());
    #endif
    }
    
    int main()
    {
         bunchOfParams bop;
         memset(&bop,0,sizeof(bop));
         bop.promptString = "This is the prompt.";
         function(bop);
         return 0;
    }
    In this case, would the string or char* be faster? This is a lot closer to the actual situation in my program, and I thought the char* would be faster although I used a std::string just for the heck of it.
    Just Google It. √

    (\ /)
    ( . .)
    c(")(") This is bunny. Copy and paste bunny into your signature to help him gain world domination.

  13. #13
    Open to suggestions Brighteyes's Avatar
    Join Date
    Mar 2003
    Posts
    204
    >In this case, would the string or char* be faster?
    Is there a performance problem with std::strings? If not then why are you even bothering to find out which is faster? Such micro optimization is counter-productive since it's usually not needed. The best advice is to use whatever results in the simplest and cleanest code, then if you have speed problems you should profile the program and find out where the bottleneck is, then fix that part and check for any more bottlenecks.
    p.s. What the alphabet would look like without q and r.

  14. #14
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    Never memset the memory of a class!!!
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #15
    Registered User
    Join Date
    Feb 2002
    Posts
    114
    I've written my own string class, and compared that with std::string... I find it pretty hard to beat performance of the std::string... For some operations: yes, but overall? no way... If anyone have, let me know

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 13
    Last Post: 12-14-2007, 02:34 PM
  2. std::string: Has my compiler gone nuts??
    By Andruu75 in forum C++ Programming
    Replies: 9
    Last Post: 09-28-2007, 04:02 AM
  3. Improving my code
    By rwmarsh in forum C++ Programming
    Replies: 14
    Last Post: 07-08-2006, 11:18 AM
  4. Debugging help
    By cuddlez.ini in forum C++ Programming
    Replies: 3
    Last Post: 10-24-2004, 07:08 PM
  5. DLL and std::string woes!
    By Magos in forum C++ Programming
    Replies: 7
    Last Post: 09-08-2004, 12:34 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21