CPU Speed Test: using 2 types of strings classes

Attached to this post is a small Windows utility which tests the comparative speed of two string classes (MFC's CString and CStr). When you run it, a window is displayed saying "All tests succeeded!" (these are internal validity checks). When you click OK, the actual comparison tests will be performed (do not use your machine during this time).

On my speed demon DELL Inspiron 8100 Pentium-III M 1.2GHz (133 MHz FSB), 512 MB RAM, I get the following results:

CString : 9834 ms
CStr : 1122 ms.

I'd be interested in seeing other peoples results on newer faster machines/processors

 

I'd like to see the source code. It's awfully easy to construct inaccurate tests...

Also, what exactly are you trying to find out? The most efficient way to manipulate strings? Usually, the fastest option is to avoid strings internally.

Anyway, I got 4391/328

(What exactly is CStr anyway? const char*? std::string? Something else?)

 

The source code for the CStr class can be downloaded from

http://www.codeproject.com/string/yasr.asp

It is a string class based on arrays. The actual speed test code can be seen in the following post on the articles message board

http://www.codeproject.com/string/yasr.asp?df=100&forumid=15839&select=540851#xx540851xx


I'm interested in finding out:

a) the best string class on all types of processor, along with the performance difference between the two classes.

b) To see if the CString implementation is faster than CStr on any configurations.

c) How fast newer machines are at string manipulation compared to my laptop.

What's the specs of your laptop ?

 

I ran this on my desktop. Athlon 64 3200+ with 1GB RAM.

Anyway, I'd seriously recommend *not* using that.
I'd also stay away from the MFC string (because it's MFC).
What exactly is wrong with std::string? It's standard and it's efficient. And it's guaranteed bug-free.

- throws() is universally discouraged, by the C++ standards committee, by compiler writers, by everyone.
- Implicit casts to numeric types is a lousy idea.
- The interface is not exactly consistent.
If I do this:
CStr s = 12, s will be a string containing the value "12"
But if I do this:
CStr s(12), s will be an empty string with a buffer size of 12.
And please don't ask me how the built-in numeric casts will work.

- It won't work very well with unicode, despite the author's claims. The buffer size is manipulated in terms of bytes, not characters (which would be 2 bytes for unicode). So for unicode, that will quickly become a mess, and I'm not at all sure it's correct, even.

- Finally, it's just not very well designed. What happened to the idea that "one class should have one single area of responsibility"?
Here we have a class that's responsible for storing allowing access to a string *and* also appending, prepending, truncating, searching in, formatting, parsing strings *and* numbers, and also implement its own resizeable container, a lá std::vector.

 

I ran the same tests on std::string and I got speeds similar to MFC's CString, maybe slightly faster. For most projects, I would agree that it is far better to use std::string, but when speed (along with a similar CString interface) is needed I would sway towards using CStr.

 

I wouldn't. Not until I had reasonable evidence that it was also *correct*.

Also, if string comparisons are performance-critical in your code, it sounds like a design flaw more than anything else. Use a data type that lends itself more to efficient comparisons instead. Or store them in a data structure that requires fewer comparisons.

Also, out of curiosity, what happens if you benchmark the two types in the opposite order? All other things being equal, I'd expect #1 to be slower because it's running on a cold cache, and because memory allocations may be more expensive the first time around. (Afterwards, Windows keeps the memory reserved, afaik, so it can quickly reallocate)

 

When running in reverse order (ie. CStr first, CString second), I get

CString : 11307
CStr : 671

so it would appear that the test executes faster when running first, at least on a P-III M 1.2GHz.