String performance

[James Kanze]

[...]

Actually I am afraid that you are now comparing the difference
between itoa() and ToString(). ToString() is probably not as
fast as itoa() since it performs a culture-aware conversion.

What does "culture-aware" mean? In C, itoa depends on the
locale.

 

[Guest]

[...]

Actually I am afraid that you are now comparing the difference
between itoa() and ToString(). ToString() is probably not as
fast as itoa() since it performs a culture-aware conversion.

What does "culture-aware" mean? In C, itoa depends on the
locale.

Not sure really, the .Net framework is not something I have studied in
detail. I am not sure what the difference between locale and culture is,
it might be two names for the same thing, but calling ToString() with no
arguments involves getting the culture object of the current thread,
from there you get a format provider object which will be used to format
the text representation of the object the function was called on.

While itoa() might also produce different output depending on the
current locale I do not think that it is quite as complicated as in
..Net, and to make things more fun ToString() is a virtual function
inherited from Object.

Nitpick: Of course, in C (as in standard C) itoa() is not defined.

 

[Lance Diduck]

The flaw is that using a different allocator changes the type of container.
So vector with allocator A1 has different type than vector with allocator
A2. You cannot write non-templated function that works with vector
regardless of its allocator.

cheers,
Marcin

It is possible to write STL containers (including strings) that use
"polymorphic allocators" such that changing the allocator does not
change the type. See http://www.lancediduck.com/papers/Cpp/StatefulSTL.pdf
I worked for a company recently that has an obsession with fixing this
"flaw" in standard container allocators--so much so that they actually
wrote their own version of the Standard libraries that "fixed" this.
And indeed, everyone could use std containers where you could pass in
a pointer to whatever allocator you dreamt up.
The resulting mess was beyond description, but suffice it to say that
those of us that actually had to build working scalable robust systems
quickly learned how to put the "change my type" allocators back in.
I hear over and over that the std allocator scheme is "broken"
"flawed" and such. And indeed it is hard to use. There are several
proposals for "improving" the allocators, two of which look promising
(N2035 and N1953). But often the fix is far worse than the problem.
In C++, by default, when you change the allocator (container or
otherwise) you change the type. This has been a feature of C++ since
Cfront 1.0. Using allocators that do not change the type is an option,
and this technique was use even in early C++. However, allocators that
know about the type of object they create allows many optimizations.

Java/C# use a form of the allocator that has O(1) heap allocations. C/C
++ typically use a system that has O(lg n) profile. This is why C/C++
will be at a disadvantage over Java/C# when making variable sized
objects such as vectors and strings, esp when using the default
allocator. But it is fairly easy (and seems to be a lost art) to make
a O(1) allocators in C++, as long as the allocator know about the type
of object being created. And you get to keep the destructors.

Lance

 

[Old Wolf]

One reason may be that C++ string is constructed from a const char *
pointer. This is a fatal C/C++ flaw - the size of such string is unknown,
even if it's given at compile time as literal such as "foo". To find out the
size, the string must be scanned at runtime for 0 character.

Granted you can eventually write a program in C++ that is faster than
C# version. But you must try really hard and go very low. Forget any nice
abstractions like std::string. To be faster you have to use strlen, strcmp,

You don't have a clue what you are talking about.
First you say that it is a flaw that you scan
the string for a 0 character at runtime. And then you
say that to make the program faster, you should call
functions that scan for 0 instead of using the stored length.

 

[Juha Nieminen]

Forget any nice
abstractions like std::string. To be faster you have to use strlen, strcmp,

How exactly will strlen() be faster than string::length(), given that
the latter just reads the value of a variable while the former always
scans the string?

 

[keith]

I have recently done a simple measurement of std::string performance in C++,
and I'm shocked how bad it is. <snip>

This probably ought to be in the FAQ. Very very often, when someone
says "Look, the performance of X is crap; my test code proves it!",
either their code is not measuring what they think it is (as in your
case), or their code is responsible for the crap performance, or
both. Don't guess - get a profiler.