std::string performance (Sun implementation)

[jortizclaver]

Hi,

I'm about to develop a new framework for my corporative applications
and my first decision point is what kind of strings to use: std::string
or classical C char*.

Performance in my system is quite importante - it's not a realtime
system, but almost - and I concern about std::string performance in
terms of speed. No doubt to use std implementation is a lot easier but
I can't sacrifice speed.

I'm using Sun Workshop 6. A very basic test shows processing with
std::string can be 3 times slower than using char*. Is there any
improvement in later versions?

Thanks,
Jorge Ortiz

[Marcelo Pinto]

jortizclaver escreveu:

Hi,

I'm about to develop a new framework for my corporative applications
and my first decision point is what kind of strings to use: std::string
or classical C char*.

Performance in my system is quite importante - it's not a realtime
system, but almost - and I concern about std::string performance in
terms of speed. No doubt to use std implementation is a lot easier but
I can't sacrifice speed.

AFAIK, one of the main problems with string performance is the time
spent (re) allocating space for the string, if you know beforehand the
size of the strings you will be dealing with you could use the reserve
member function of string class.

If I was in your place I would use strings for simplicity and security.
When I detected a problem with performance (by profiling) I would
strugle to solve it ("premature optimization is the root of all evil"
Hoare).
I'm using Sun Workshop 6. A very basic test shows processing with
std::string can be 3 times slower than using char*. Is there any
improvement in later versions?
The difference in performance could be due to the allocation problem I
mentioned, but I don't know Sun Workshop 6.

Thanks,
Jorge Ortiz

HTH,

Marcelo Pinto

[dagrabber]

C style strings is more faster that std::string, and almost things that
u can do with std::string u can do with C style strings

C style functs:
http://cermics.enpc.fr/~ts/C/FUNCTIO...ef.html#string

[mlimber]

Reposting since Google Groups seems to be having problems.

jortizclaver wrote:

Hi,

I'm about to develop a new framework for my corporative applications
and my first decision point is what kind of strings to use: std::string
or classical C char*.

Performance in my system is quite importante - it's not a realtime
system, but almost - and I concern about std::string performance in
terms of speed. No doubt to use std implementation is a lot easier but
I can't sacrifice speed.

I'm using Sun Workshop 6. A very basic test shows processing with
std::string can be 3 times slower than using char*. Is there any
improvement in later versions?

Thanks,
Jorge Ortiz

First, speed is implementation-dependent -- both compiler and library.
Since I presume you don't want to change compilers, you may be able to
find a faster library implementation (e.g., STLPort, Dinkumware, etc.).
Also, you might try fiddling with the switches for your compiler. On
some compilers, if you don't specify an optimization level, the
compiler doesn't even inline functions, which is a speed killer for the
C++ standard library in general. For more on these sorts of concerns,
you may want to consult a newsgroup (or list or whatever) that is more
familiar with your particular compiler and library.

Second, we might question the validity of your test. If you didn't
factor in the extra (read: manual, error-prone, often tedious) work
you'll have to do with arrays to validate lengths, prevent buffer
overflows, allocate and deallocate, etc., then it might not be a fair
test. See this FAQ for some more thoughts on why standard containers
should be preferred over arrays:

http://www.parashift.com/c++-faq-lit....html#faq-34.1

Finally, let me remind you to beware premature optimization. Guru
Sutter reminds us about the rules for optimizing
(http://www.gotw.ca/publications/mill09.htm):

"1. Don't optimize early. 2. Don't optimize until you know that it's
needed. 3. Even then, don't optimize until you know *what* [is] needed,
and *where*.

"By and large, programmers--that includes you and me--are notoriously
bad at guessing the actual space/time performance bottlenecks in their
own code. If you don't have performance profiles or other empirical
evidence to guide you, you can easily spend days optimizing something
that doesn't need optimizing and that won't measurably affect runtime
space or time performance. What's even worse, however, is that when you
don't understand what needs optimizing you may actually end up
pessimizing (degrading your program) by of saving a small cost while
unintentionally incurring a large cost. Once you've run performance
profiles and other tests, and you actually know that a particular
optimization will help you in your particular situation, then it's the
right time to optimize."

Cheers! --M

[Ben Pope]

da*******@gmail.com wrote:

C style strings is more faster that std::string,
Are they, in general?
and almost things that
u can do with std::string u can do with C style strings
Yes. The other things that are really easy with C-Style strings are
buffer overruns and much other undefined behaviour.
C style functs:
http://cermics.enpc.fr/~ts/C/FUNCTIO...ef.html#string

By the time you have correctly, managed your C-Style strings, ensuring
to keep track of the length, add your null termination, feed the
functions with the buffer length less 1, in some situations etc., etc.,
you will probably find that, apart from your code becoming cluttered
with many more lines managing the char array, speed is similar.

Of course, if you don't mind a bit of undefined behaviour here and
there, you don't need to bother with the checks, in which case, yes,
C-style strings are often marginally faster to mess around with.
Alternatively, get the code written correctly in much less time by using
std::string, and if the performance is not good enough, spend the time
saved to ensure your strings are allocated with enough space to avoid
reallocations when you concatenate, and feel free to play with the
allocator if you can do a better job then the provided one.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Kai-Uwe Bux]

jortizclaver wrote:

I'm about to develop a new framework for my corporative applications
and my first decision point is what kind of strings to use: std::string
or classical C char*.

Performance in my system is quite importante - it's not a realtime
system, but almost - and I concern about std::string performance in
terms of speed. No doubt to use std implementation is a lot easier but
I can't sacrifice speed.
Library design is tricky. Usually, std::string implementations will beat
char* solutions on common problems, unless the char* solution is carefully
optimized. The reason is that the std::string implementation can use fancy
stuff like reference counted copy on write and/or short string optimization
to make many operations faster than their naive char* counter parts.

On the other hand, the library implementor has no idea about your particular
application. Thus, the optimizations in the library may turn out to be
pessimizing in a particular case.
I'm using Sun Workshop 6. A very basic test shows processing with
std::string can be 3 times slower than using char*. Is there any
improvement in later versions?

I have a hard time believing that. Could you post your benchmarking code?
Best

Kai-Uwe Bux

[jortizclaver]

> C style strings is more faster that std::string, and almost things that

u can do with std::string u can do with C style strings
You,re right, no doubt. But let's think you're designing a framework
that will be used by many different profiled programmers (from newies
to ten years experienced). Using STD containers and strings put system
robustness far away from unexperienced hands.
Also, you might try fiddling with the switches for your compiler. On
some compilers, if you don't specify an optimization level, the
compiler doesn't even inline functions, which is a speed killer for the
C++ standard library in general.
Already done. I've compiled test programs with optimizacion flags.
Second, we might question the validity of your test. If you didn't
factor in the extra (read: manual, error-prone, often tedious) work
you'll have to do with arrays to validate lengths, prevent buffer
overflows, allocate and deallocate, etc., then it might not be a fair
test.
It's an interesting point of view but my comparison already includes
all this validation process. Probably test does not include exactly the
same funcionality for both implementations but it doesn't justify
performance difference.

See this FAQ for some more thoughts on why standard containers
should be preferred over arrays:
http://www.parashift.com/c++-faq-lit....html#faq-34.1
I agree containers are a lot better than arrays. My dilemma is between
std::string and char*. Map/vector performance is fine.
"1. Don't optimize early. 2. Don't optimize until you know that it's
needed. 3. Even then, don't optimize until you know *what* [is] needed,
and *where*.

I can't agree on that. Most of the times when you realize you have
performance problems is too late for going back. Sometimes you can't
predict how you'll system will work but at least you should start from
a advantageous point.

Regards,
Jorge

[jortizclaver]

> Library design is tricky. Usually, std::string implementations will beat

char* solutions on common problems, unless the char* solution is carefully
optimized. The reason is that the std::string implementation can use fancy
stuff like reference counted copy on write and/or short string optimization
to make many operations faster than their naive char* counter parts.
I'm sure it works in that way with g++ implementation or other
libraries but Sun's doesn't seem to be very good.
I have a hard time believing that. Could you post your benchmarking code?

Believe me, I'd like to be wrong :-)

I've made many tests. One of them is a very basic test program someone
sent to another C++ newsgroup:
http://groups.google.com/group/comp....d1ffef4fd97668

1570000:using assign,append
650000:using C strings

Regards,
Jorge

[mlimber]

jortizclaver wrote:

Hi,

I'm about to develop a new framework for my corporative applications
and my first decision point is what kind of strings to use: std::string
or classical C char*.

Performance in my system is quite importante - it's not a realtime
system, but almost - and I concern about std::string performance in
terms of speed. No doubt to use std implementation is a lot easier but
I can't sacrifice speed.

I'm using Sun Workshop 6. A very basic test shows processing with
std::string can be 3 times slower than using char*. Is there any
improvement in later versions?

Thanks,
Jorge Ortiz

First, speed is implementation-dependent -- both compiler and library.
Since I presume you don't want to change compilers, you may be able to
find a faster library implementation (e.g., STLPort, Dinkumware, etc.).
Also, you might try fiddling with the switches for your compiler. On
some compilers, if you don't specify an optimization level, the
compiler doesn't even inline functions, which is a speed killer for the
C++ standard library in general. For more on these sorts of concerns,
you may want to consult a newsgroup (or list or whatever) that is more
familiar with your particular compiler and library.

Second, we might question the validity of your test. If you didn't
factor in the extra (read: manual, error-prone, often tedious) work
you'll have to do with arrays to validate lengths, prevent buffer
overflows, allocate and deallocate, etc., then it might not be a fair
test. See this FAQ for some more thoughts on why standard containers
should be preferred over arrays:

http://www.parashift.com/c++-faq-lit....html#faq-34.1

Finally, let me remind you to beware premature optimization. Guru
Sutter reminds us about the rules for optimizing
(http://www.gotw.ca/publications/mill09.htm):

"1. Don't optimize early. 2. Don't optimize until you know that it's
needed. 3. Even then, don't optimize until you know *what* [is] needed,
and *where*.

"By and large, programmers--that includes you and me--are notoriously
bad at guessing the actual space/time performance bottlenecks in their
own code. If you don't have performance profiles or other empirical
evidence to guide you, you can easily spend days optimizing something
that doesn't need optimizing and that won't measurably affect runtime
space or time performance. What's even worse, however, is that when you
don't understand what needs optimizing you may actually end up
pessimizing (degrading your program) by of saving a small cost while
unintentionally incurring a large cost. Once you've run performance
profiles and other tests, and you actually know that a particular
optimization will help you in your particular situation, then it's the
right time to optimize."

Cheers! --M

[mlimber]

jortizclaver wrote:

C style strings is more faster that std::string, and almost things that
u can do with std::string u can do with C style strings

You,re right, no doubt. But let's think you're designing a framework
that will be used by many different profiled programmers (from newies
to ten years experienced). Using STD containers and strings put system
robustness far away from unexperienced hands.

First, please don't quote multiple authors in the same post without
identifying them. Respond to each post individually or at least give
proper attribution. Second, I have no idea what your last sentence
means. Please clarify.

In any case, if you want people to *use* this framework, it must work,
and as the saying goes, "It's far easier to make a correct program fast
than to make a fast program correct." In that regard standard
containers and strings are invaluable (see below).

Also, you might try fiddling with the switches for your compiler. On
some compilers, if you don't specify an optimization level, the
compiler doesn't even inline functions, which is a speed killer for the
C++ standard library in general.

Already done. I've compiled test programs with optimizacion flags.

At the risk of some redundancy, what about checking different
implementations of the standard library?

Second, we might question the validity of your test. If you didn't
factor in the extra (read: manual, error-prone, often tedious) work
you'll have to do with arrays to validate lengths, prevent buffer
overflows, allocate and deallocate, etc., then it might not be a fair
test.

It's an interesting point of view but my comparison already includes
all this validation process. Probably test does not include exactly the
same funcionality for both implementations but it doesn't justify
performance difference.

Show us the code you used to gather your metrics. Then we can discuss
it more fully.

See this FAQ for some more thoughts on why standard containers
should be preferred over arrays:
http://www.parashift.com/c++-faq-lit....html#faq-34.1

I agree containers are a lot better than arrays. My dilemma is between
std::string and char*. Map/vector performance is fine.

Ok, ok: std::string is not technically a standard container per se.
However, in this context, I would suggest that a comparison of
std::string vs. char* is similar enough to std::vector<int> vs. int*
that almost all of the same reasoning applies.

"1. Don't optimize early. 2. Don't optimize until you know that it's
needed. 3. Even then, don't optimize until you know *what* [is] needed,
and *where*.

I can't agree on that. Most of the times when you realize you have
performance problems is too late for going back. Sometimes you can't
predict how you'll system will work but at least you should start from
a advantageous point.

<Booming voice>: Who dares contradict Guru Sutter (and Uber-Gurus Knuth
and Hoare)?!

Sutter (with Alexandrescu) advises: "When writing libraries, it's
harder to predict what operations will end up being used in
performance-sensitive code. But even library authors run performance
tests against a broad range of client code before committing to
obfuscating optimizations." (_C++ Coding Standards_, p. 17).

And the same book argues that we should nearly always "[a]void
implementing array abstractions with C-style arrays, pointer
arithmetic, and memory management primitives. Using vector or string
not only makes your life easier, but also helps you write safer and
more scalable software.... Buffer overruns and security flaws are,
hands down, a front-running scourge of today's software.... Most of
these are caused by using bare C-level facilities--such as build-in
arrays, pointers and pointer aritmetic, and manual memory
management--as a substitute for higher-level concepts such as buffers,
vectors, or strings." (p. 152).

You can disagree with them all you want, but I would suggest than more
people trust their opinion than yours, and for good reason.

Cheers! --M

[Gavin Deane]

jortizclaver wrote:

See this FAQ for some more thoughts on why standard containers
should be preferred over arrays:
http://www.parashift.com/c++-faq-lit....html#faq-34.1
I agree containers are a lot better than arrays. My dilemma is between
std::string and char*. Map/vector performance is fine.

What's the difference between "string vs char*" where you seem to
favour reinventing the wheel and "map/vector vs handcoded equivalent"
where you seem happy to use the wheel you've been given?

"1. Don't optimize early. 2. Don't optimize until you know that it's
needed. 3. Even then, don't optimize until you know *what* [is] needed,
and *where*.

I can't agree on that.

Then I expect you are in the minority, with much weight of advice
against you. For an appropriate definiton of "early" of course.
Most of the times when you realize you have
performance problems is too late for going back. Sometimes you can't
predict how you'll system will work but at least you should start from
a advantageous point.

Yes you should start from an advantageous point, but not the point you
are thinking of. It is advantageous to start your optimisation effort
from the point of having correct working code (perhaps with unit tests
around it if appropriate). Not only is it generally much easier to
target bottlenecks and speed up correct code then it is to fix the more
complex and buggy code that results from reinventing the wheel, but
also, on all those occasions where it turns out that your correct code
happens already to be fast/small enough, you have reached your
detination in the quickest and most painless way.

Gavin Deane

[Markus Moll]

Hi

da*******@gmail.com wrote:

C style strings is more faster that std::string, and almost things that
u can do with std::string u can do with C style strings

I can easily imagine cases where std::string outperforms C-style strings by
lengths, so I would be careful with statements like that. (Honestly, I
doubt that any good std::string implementation would be slower than the
C-style equivalent).

Besides, C-style strings make it quite easy to invoke undefined behavior.

E.g:

(C code using char*)
--- snip ---

#include <string.h>
#include <stdio.h>

int main()
{
char *s = "Hello world. This is an unnecessarily long string.";
unsigned i;
unsigned total = 0;
for(i=0; i!=1000000; ++i)
total += strlen(s);
printf("%d\n", total);
return 0;
}

--- snip ---

times
real 0m0.044s
user 0m0.038s
sys 0m0.000s

where

(C++ code using std::string)
--- snip ---

#include <string>
#include <cstdio>

int main()
{
std::string s = "Hello world. This is an unnecessarily long
string.";
unsigned total = 0;
for(unsigned i=0; i!=1000000; ++i)
total += s.length();
std::printf("%d\n", total);
}

--- snip ---

times

real 0m0.006s
user 0m0.004s
sys 0m0.002s

(both compiled with GCC 3.3.5 and -O2)

cheers
Markus

[jortizclaver]

>> You,re right, no doubt. But let's think you're designing a framework

that will be used by many different profiled programmers (from newies
to ten years experienced). Using STD containers and strings put system
robustness far away from unexperienced hands.
First, please don't quote multiple authors in the same post without
identifying them. Respond to each post individually or at least give
proper attribution. Second, I have no idea what your last sentence
means. Please clarify.

Using char* implies managing memory. I don't trust in unexperienced
hands for that task. If I can hide memory management using std::string
I'd feel a lot better.
You can disagree with them all you want, but I would suggest than more
people trust their opinion than yours, and for good reason.

Yeah, I'm brave! Probably my "mistake" was to understand those words in
a different way.

I'll use a very simple example. Let's say you need to implement a
real-time system where speed is definitively the main issue and where
you need to run thousands of concurrent threads for accomplish really
complex tasks. Would you use Java? I wouldn't as I know C/C++
performance can be a lot better (of course, there are other important
details that can make me change that decission). How do you apply your
guru's teachings to this case? Would you call this premature
optimization?

That's what I meaned. It's important to choose carefully the components
of your architecture and the libraries and third party tools you'll use
are part of them.

Regards,
Jorge

P.S: BTW, man, do you have all those books you talk about in your mind?
I'm impressed:-)

[Ben Pope]

jortizclaver wrote:

I agree containers are a lot better than arrays. My dilemma is between
std::string and char*. Map/vector performance is fine.

Then use std::vector<char> ;-)

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Alex Vinokur]

"jortizclaver" <jo**********@gmail.com> wrote in message news:11*********************@g14g2000cwa.googlegro ups.com...

Hi,

I'm about to develop a new framework for my corporative applications
and my first decision point is what kind of strings to use: std::string
or classical C char*.

[snip]

Look at C/C++ Performance Tests:
http://alexvn.freeservers.com/s1/per...ts/pftests.htm

--
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

[Ben Pope]

Alex Vinokur wrote:

"jortizclaver" <jo**********@gmail.com> wrote in message news:11*********************@g14g2000cwa.googlegro ups.com...

Hi,

I'm about to develop a new framework for my corporative applications
and my first decision point is what kind of strings to use: std::string
or classical C char*.

[snip]

Look at C/C++ Performance Tests:
http://alexvn.freeservers.com/s1/per...ts/pftests.htm

"Compilation : No optimization"

Is that how most people release code? I thought -02 would be a minimum
for most release code concerned about performance.

What have I missed?

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[mlimber]

jortizclaver wrote:

Using char* implies managing memory. I don't trust in unexperienced
hands for that task. If I can hide memory management using std::string
I'd feel a lot better.
Amen and amen. But you're making my case for me!
I'll use a very simple example. Let's say you need to implement a
real-time system where speed is definitively the main issue and where
you need to run thousands of concurrent threads for accomplish really
complex tasks. Would you use Java? I wouldn't as I know C/C++
performance can be a lot better (of course, there are other important
details that can make me change that decission). How do you apply your
guru's teachings to this case? Would you call this premature
optimization?
If speed is definitively the main issue, then yes you should use
arrays/pointers. If correctness, usability, marketability, ease of
maintenance, quality, etc. were major factors in your project, I would
suggest you should use std::string throughout. The Gurus' (plural)
advice on the matter would likely be that with such a complex program,
it will be nearly impossible to track down all the security flaws,
buffer overflows, etc. that will be incurred by even the most careful
and meticulous programmer. Depending on your knowledge of how the
framework will be used, you may be able to measure for true (rather
than speculative) bottlenecks and hand tune those parts of the code.

On the other hand, if you insist on doing things by hand, Java might be
the way to go since its garbage collection would help clean up after
your mistakes. ;-)
It's important to choose carefully the components
of your architecture and the libraries and third party tools you'll use
are part of them.

Agreed, which is why we recommend you use robust, standard tools that
are part of the language rather than building your software built on a
more fragile foundation.

Cheers! --M

[mlimber]

jortizclaver wrote:

I have a hard time believing that. Could you post your benchmarking code?

Believe me, I'd like to be wrong :-)

I've made many tests. One of them is a very basic test program someone
sent to another C++ newsgroup:
http://groups.google.com/group/comp....d1ffef4fd97668

A number of people noted flaws in that test program. See the rest of
the thread. Also, someone else recommended the use of a different
library implementation such as STLPort, whose allocators are supposed
to be superior. Now, I hate to repeat myself over and over, but you
have not responded to a similar suggestion in two of my posts above.
May I humbly recommend you try a different implementation?

BTW, the standard committee's "Technical Report on C++ Performance"
(http://www.research.att.com/~bs/performanceTR.pdf) has this caveat
about std::string for unchangeable strings: "The Standard class
std::string is not a lightweight component. Because it has a lot of
functionality, it comes with a certain amount of overhead.... In many
applications, strings are created, stored, and referenced, but never
changed. As an extension, or as an optimization, it might be useful to
create a lighter-weight, unchangeable string class."

Cheers! --M

[Ian Collins]

jortizclaver wrote:

Library design is tricky. Usually, std::string implementations will beat
char* solutions on common problems, unless the char* solution is carefully
optimized. The reason is that the std::string implementation can use fancy
stuff like reference counted copy on write and/or short string optimization
to make many operations faster than their naive char* counter parts.

I'm sure it works in that way with g++ implementation or other
libraries but Sun's doesn't seem to be very good.

You are using a very old, unsupported version of the compiler.

Try something newer.

--
Ian Collins.

[Default User]

mlimber wrote:

jortizclaver wrote:

I'll use a very simple example. Let's say you need to implement a
real-time system where speed is definitively the main issue and
where you need to run thousands of concurrent threads for
accomplish really complex tasks.

If speed is definitively the main issue, then yes you should use
arrays/pointers. If correctness, usability, marketability, ease of
maintenance, quality, etc. were major factors in your project, I would
suggest you should use std::string throughout.

Often with real-time projects it isn't the speed of operations that's
the problem. The reason std::string and others can't be used (or have
to be used carefully) is that memory allocation during program run is
often forbidden. Consistency of program cycles is more important that
the speed. You have to know what the bounds of your program run cycle
is, you can't have it vary much.

You can use standard containers if they're sized at start-up and no
operations are performed that will cause the size to shift. That means
avoid many of the cool operators and such.


Brian

[mlimber]

Default User wrote:

mlimber wrote:

jortizclaver wrote:

I'll use a very simple example. Let's say you need to implement a
real-time system where speed is definitively the main issue and
where you need to run thousands of concurrent threads for
accomplish really complex tasks.

If speed is definitively the main issue, then yes you should use
arrays/pointers. If correctness, usability, marketability, ease of
maintenance, quality, etc. were major factors in your project, I would
suggest you should use std::string throughout.

Often with real-time projects it isn't the speed of operations that's
the problem. The reason std::string and others can't be used (or have
to be used carefully) is that memory allocation during program run is
often forbidden. Consistency of program cycles is more important that
the speed. You have to know what the bounds of your program run cycle
is, you can't have it vary much.

You can use standard containers if they're sized at start-up and no
operations are performed that will cause the size to shift. That means
avoid many of the cool operators and such.

Agreed. Or you can use containers/strings with a custom allocator,
e.g., one that uses a pre-allocated area of memory for its operations.
In any case, efficiency, not memory allocation, was the chief
constraint laid out by the OP.

Cheers! --M

[Roland Pibinger]

On 26 Jan 2006 11:16:48 -0800, "mlimber" <ml*****@gmail.com> wrote:

Also, someone else recommended the use of a different
library implementation such as STLPort, whose allocators are supposed
to be superior.

"Standard C++ string class. This class has performance
characteristics very much like vector<>, meaning, for example, that it
does not perform reference-count or copy-on-write, and that
concatenation of two strings is an O(N) operation."

quoted from: STLport-4.6.2\stlport\stl\_string.h

Best regards,
Roland Pibinger

[rapool]

Markus Moll wrote:

#include <string.h>
#include <stdio.h>
int main()
{
char *s = "Hello world. This is an unnecessarily long string.";

unsigned i;
unsigned total = 0;
for(i=0; i!=1000000; ++i)
total += strlen(s);
printf("%d\n", total);
return 0;
}

I just change this source code like this,

int main()
{
char *s = "Hello world. This is an unnecessarily long string.";

unsigned i;
unsigned total = 0;
unsigned size = strlen(s);

for(i=0; i!=1000000; ++i)
total += size;
printf("%d\n", total);
return 0;
}

The result shows three times faster than std::string.
I did another test.

int function1 ()
{
unsigned i;
unsigned total = 0;

for(i=0; i!=10000000; ++i)
{
char *s = "Hello world. This is an unnecessarily long string.";
total += strlen(s);
}

printf("%d\n", total);
return 0;
}

int function2 ()
{
unsigned total = 0;

for (unsigned i=0; i != 10000000; i++)
{
std::string s = "Hello world. This is an unnecessarily long
string.h";
total += s.length();
}

std::printf("%d\n", total);
return 0;
}

The function1 is ten times faster than function2.
In my opinion, although std::string can be good solution
for developing application, it is not for framework.

[jortizclaver]

I tried yesterday using Sun Workshop 10 and linking with the STLPort
libraries it includes and I have to say execution times has plummeted
about 30% and now difference between char* implementation and
std::string is not that big. Using a very very basic test program, it's
a 1:1.5 ratio (no doubt in other tasks std::strings will beat char*)
Those results are perfectly valid for me. I think I'll use strings.

Thanks,
Jorge

[jortizclaver]

> > Using char* implies managing memory. I don't trust in unexperienced

hands for that task. If I can hide memory management using std::string
I'd feel a lot better.
Amen and amen. But you're making my case for me!

I'm not discussing which one is better in terms of memory managment or
friendly use, I'm just trying to evaluate std::string performance so I
can keep my job after this project. I do prefer using std::string but I
need to be sure they don't slow my process down dramatically.
Depending on your knowledge of how the
framework will be used, you may be able to measure for true (rather
than speculative) bottlenecks and hand tune those parts of the code.

That's the case. I've been working in this company for five years so I
know exactly where the problems are. And performance passing data
forward and backward is one of them. That's why I concern std::string
performance.

Regards,
Jorge

[Patrick Kowalzick]

Hello Jorge,

I think I'll use strings.

You could use your own typedefs:

*** jcstring.h ***

#include <string>

namespace jc
{
typedef std::string string;
typedef std::wstring wstring;
}

This will make it easier to change to a different allocator later. On the
other hand it is getting a little bit nasty if you have interfaces with a
std::string and want to feed a jc::string (and vice versa). So, keep it
consistent :).

Even if performance is fine now, there are other benefits of an own
allocator (e.g. lower fragmentation for long term stability).

Good luck,
Patrick

[Nitin Motgi]

Ben Pope wrote:

da*******@gmail.com wrote:
Yes. The other things that are really easy with C-Style strings are
buffer overruns and much other undefined behaviour.

Reece H. Dunn has a fixed_string implementation that tries to solve
this problem (buffer over flow) and still use C-Style Strings. It's
currently being reviewed by for inclusion into boost library.

C style functs:
http://cermics.enpc.fr/~ts/C/FUNCTIO...ef.html#string

By the time you have correctly, managed your C-Style strings, ensuring
to keep track of the length, add your null termination, feed the
functions with the buffer length less 1, in some situations etc., etc.,
you will probably find that, apart from your code becoming cluttered
with many more lines managing the char array, speed is similar.

Notion behind fixed_string is really good. It's neat and does not look
cluttered. It adds a little over head but I have been using it and till
now it seems good.
Thank you,
Nitin Motgi
[ Just My Thoughts ]

[persenaama]

This code, and the one that Markus posted earlier don't really show
either std::strlen or std::string::length to be any faster than the
other, just ways to use either poorly, and that description only holds
when it makes any real world difference.

You can write less than good code with either, it is also possible to
write good code with either. All it takes is experience and a brain to
capitalize on it... agreed?

The biggest advantage of std::string is the management of the object's
member data, it makes higher level code easier to write and read,
basicly less maintenance required so I tend to personally go with that
approach. Most of the code I write isn't performance critical, actually
very little is. On the other hand, most applications or parts of
application I write, could easily be bottlenecks (I write graphics
drivers for embedded graphics processors) but then again, in that field
code is never fast enough, so better do architechtural decisions that
are wise and leave implementation less headroom to cause problems. But
that's not very interesting to the rest of the world. :)

[persenaama]

Am I the only one to miss the point of these performance comparisons
you posted, but why compile the code to be as slow as possible when
trying to decide which is faster? I don't get it?

[Ben Pope]

persenaama wrote:

Am I the only one to miss the point of these performance comparisons
you posted, but why compile the code to be as slow as possible when
trying to decide which is faster? I don't get it?

I believe I made the same comment, no optimisations in the code. I
don't understand.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[mlimber]

jortizclaver wrote:

I tried yesterday using Sun Workshop 10 and linking with the STLPort
libraries it includes and I have to say execution times has plummeted
about 30% and now difference between char* implementation and
std::string is not that big. Using a very very basic test program, it's
a 1:1.5 ratio (no doubt in other tasks std::strings will beat char*)
Those results are perfectly valid for me. I think I'll use strings.

Thanks,
Jorge

Glad we could help. :-)

Cheers! --M

[Daniel T.]

In article <11*********************@g14g2000cwa.googlegroups. com>,
"jortizclaver" <jo**********@gmail.com> wrote:

Hi,

I'm about to develop a new framework for my corporative applications
and my first decision point is what kind of strings to use: std::string
or classical C char*.

Performance in my system is quite importante - it's not a realtime
system, but almost - and I concern about std::string performance in
terms of speed. No doubt to use std implementation is a lot easier but
I can't sacrifice speed.

I'm using Sun Workshop 6. A very basic test shows processing with
std::string can be 3 times slower than using char*. Is there any
improvement in later versions?

The C++ standard does not specify the complexity of basic_string
operations, as such there is no guarantee that std::string will be as
fast as using a C char*.

Of course, this also means you can implement your own string classes and
have them conform to the standard rather easily. Back when I first
started using string classes, the popular thing to do was to use
reference counting internally, lately most strings are implemented
basically like a vector<char>, one could however implement it in terms
of a deque<char>.

What is it you do with your strings in your program? In most programs,
different string like objects are used in different ways; some must be
able to resize, some are always a fixed size but must be able to mutate
their contents, and some always have a fixed size and fixed contents.
Some must be able to efficiently handle insertions in the middle (more
efficiently than vector<char>.

A reasonably large company with very tight performance requirements
would be best served by having several different string implementations,
using std::string for everything would probably not be the best choice;
nor would just using C char* for everything.

[persenaama]

It would interesting to see some statistics, but unlike they exist
because most have better things to do. But here's what I observed about
string class uses (from personal experience, don't try to inflict
opinion to anyone)

Most typical use I observe is to use string object to store names of
objects and similiar use: basicly, just storing text. <- doh? ;-)

Another use is stringstream / sprintf -like usage, where strings are
created from, typically from (again, just observation) binary data.
Common practise when writing to file and the format is ascii as an
example.

I can think of countless other uses aswell but those two in my
experience are present practically everywhere.

For use #1 the performance is rarely critical when constructing the
string object. When using the name for indexing somekind of fast
comparison might be useful (insertion to a map might be one place where
this is useful optimization to have?)

I could go on, but I recognize the futility of iterating my own
personal experience in lack of statistics with very large number of
samples. :()

I don't remember string performance ever being a real problem in any
application I've written. I suppose I haven't written enough
applications to worry about this. I can think of instances where it may
pose a problem, but I haven't actually written such software (yet) so I
rather not comment on that -- however -- comments by those who have are
welcome!

[roberts.noah]

jortizclaver wrote:

Hi,

I'm about to develop a new framework for my corporative applications
and my first decision point is what kind of strings to use: std::string
or classical C char*.

Performance in my system is quite importante - it's not a realtime
system, but almost - and I concern about std::string performance in
terms of speed. No doubt to use std implementation is a lot easier but
I can't sacrifice speed.

I'm using Sun Workshop 6. A very basic test shows processing with
std::string can be 3 times slower than using char*. Is there any
improvement in later versions?

You should use generic methods of accessing an object that acts like a
std::string, then you can reimplement as you need. I myself found that
profiling rarely focuses on string operations, if ever.

I did do some performance tests of std::string vs. char[]. Using
std::string poorly, such as creating unnecissary temporaries (don't use
operator +), can greately reduce execution speed if in fact you are in
an area of code that needs speed. stringstream was much faster than
sprintf but strcat was also quite a bit faster than append().

Really its a balancing act. There are many costs of using char[] that
have nothing to do with execution speed including debug time caused by
buffer overruns (code riddled with static sized char arrays can really
cost when it comes time to change features). In the end the cost of
using std::string is negligable (when used reasonably) in execution
speed but of major benefit in development time when compared to char[].
If std::string is costing too much you probably need to look closer at
your algorithm, not the string implementation.

And remember, profile before optimizing. I get into arguments with
coworkers about std::string vs. char[] all the time (their claim is the
cost of allocation which I found to be negligable - big believers in
the Clib part of C++) and std::string is never in the top of a
profile...it is always something else. On the other hand it took me 12
hours to track down a buffer overflow in a char[]...

[Alex Vinokur]

"Ben Pope" <be***************@gmail.com> wrote in message news:43**********************@taz.nntpserver.com.. .

persenaama wrote:

Am I the only one to miss the point of these performance comparisons
you posted, but why compile the code to be as slow as possible when
trying to decide which is faster? I don't get it?

I believe I made the same comment, no optimisations in the code. I
don't understand.

[snip]

The performance comparisons I posted is an example of using C++ Program Perfometer. The user can use the Perfometer to get
comparison of various algorithms for various levels of optimization.
--
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

[Roland Pibinger]

On Fri, 27 Jan 2006 13:40:47 GMT, "Daniel T." <a@b.c> wrote:

The C++ standard does not specify the complexity of basic_string
operations, as such there is no guarantee that std::string will be as
fast as using a C char*.
Right, std::string is under-specified. That forces users to program
against a concrete string implementation, not against an interface.
Should you return a string by value? Depends on the implementation.
What is the performance of vector<string>? Depends on the
implementation.
Of course, this also means you can implement your own string classes and
have them conform to the standard rather easily. Back when I first
started using string classes, the popular thing to do was to use
reference counting internally,
The most important design decision is whether copying and assignment
should be 'cheap' or 'expensive'.
lately most strings are implemented
basically like a vector<char>, one could however implement it in terms
of a deque<char>.
deque<char> is an interesting idea, albeit .c_str() could become
expensive.
What is it you do with your strings in your program? In most programs,
different string like objects are used in different ways; some must be
able to resize, some are always a fixed size but must be able to mutate
their contents, and some always have a fixed size and fixed contents.
Some must be able to efficiently handle insertions in the middle (more
efficiently than vector<char>.

A reasonably large company with very tight performance requirements
would be best served by having several different string implementations,
using std::string for everything would probably not be the best choice;
nor would just using C char* for everything.

Well said! Call them (immutable) String, StringBuilder, and
(stack-based) Buffer.

Best regards,
Roland Pibinger

[Daniel T.]

In article <43*************@news.utanet.at>,
rp*****@yahoo.com (Roland Pibinger) wrote:

On Fri, 27 Jan 2006 13:40:47 GMT, "Daniel T." <a@b.c> wrote:

The C++ standard does not specify the complexity of basic_string
operations, as such there is no guarantee that std::string will be as
fast as using a C char*.

Right, std::string is under-specified. That forces users to program
against a concrete string implementation, not against an interface.
Should you return a string by value? Depends on the implementation.
What is the performance of vector<string>? Depends on the
implementation.

Hum... You should return by value when you need to, otherwise don't...
The performance of any class depends on the implementation, the fact
that vector et al have known performance characteristics and string
doesn't is a result of the fact that the standard committee requires a
particular implementation for vector but not for string.

This is actually a boon to string implementors/users. They can customize
their particular string class to work best with their particular problem
space.

lately most strings are implemented
basically like a vector<char>, one could however implement it in terms
of a deque<char>.

deque<char> is an interesting idea, albeit .c_str() could become
expensive.

..c_str() need only be cheep if the program in question uses many
libraries that only work with 'const char*' and we often need to convert
from string to 'const char*'. In a program where such conversion is not
needed, and has lots of insertions/removals at the beginning/middle of
strings, implementing string in terms of a deque makes more sense.

I expect that a string implementation in terms of 'list' wold not be a
good idea in any case (though still technically standards conforming. :-)

What is it you do with your strings in your program? In most programs,
different string like objects are used in different ways; some must be
able to resize, some are always a fixed size but must be able to mutate
their contents, and some always have a fixed size and fixed contents.
Some must be able to efficiently handle insertions in the middle (more
efficiently than vector<char>.

A reasonably large company with very tight performance requirements
would be best served by having several different string implementations,
using std::string for everything would probably not be the best choice;
nor would just using C char* for everything.

Well said! Call them (immutable) String, StringBuilder, and
(stack-based) Buffer.

Thanks.

[Ian Collins]

Daniel T. wrote:

Right, std::string is under-specified. That forces users to program
against a concrete string implementation, not against an interface.
Should you return a string by value? Depends on the implementation.
What is the performance of vector<string>? Depends on the
implementation.

Hum... You should return by value when you need to, otherwise don't...
The performance of any class depends on the implementation, the fact
that vector et al have known performance characteristics and string
doesn't is a result of the fact that the standard committee requires a
particular implementation for vector but not for string.

This is actually a boon to string implementors/users. They can customize
their particular string class to work best with their particular problem
space.

Which is the case with this compiler, two standard libraries are
provided, one with a reference counted string that is very efficient for
passing fixed strings by value and one not reference counted (stlport).

--
Ian Collins.