Thanks for your reply.

Quote:Original post by KulSeran
1) I think you mean miliseconds (GetTickCount isn't nanoseconds)

My intention was : GetTickCount is miliseconds and since the program loops 1,000,000 times, the time measured by GetTickCount() becomes nanoseconds for one iteration. I'm too lazy to write

printf( "%f ns\n", uElapsed / 1000.0 / 1000000 /*# of iterations*/ * 1E+9 /**/ );

Quote:
2) you can always call std::string::reserve if you know you are doing a lot of
concatanations (equivelent to your wonderful buf[21] trick)

But in my opinion std::string::reserve() allocates the buffer from the heap and that's still not the same.

BTW, your word "wonderful trick" made me laugh a lot.

Quote:
3) If string are you bottleneck, and you don't NEED strings, you may as well replace them with something like CRC hashes of the strings in question.
4) If you do NEED string, you may want to rethink your algorithm anyway. Lots of temporary copies and concatenations
can be a sign of you doing it wrong to start with. Changing how you make you pass over the dataset can mean that you
don't even need to be making copies of anything.

I saw some sources written in Java and was shocked at that it's pretty fast despite of a lot of string operations. And yes, one can always optimize algorithms to minimize string operations. I'm kind of lazy in that sense. I always think about 'how to make good things without headache'.

Quote:
5) get a custom allocator for the string, especially if you know you are going to be allocating many small strings.

Could you recommend me some? I'd like to look at them so that I can optimize my heap allocator further.

Quote:You have to remember that std::blah is a GENERAL PURPOSE tool. You can always speed it up by giving it knowledge about the
current situation you are using it in. And you can probably write a faster SINGLE PURPOSE tool, but you have to weigh in the cost
of time spent on your tool vs. just using a proven library.

Thanks. Fortunately this case seems to me profitable. I think the heap I'm making now can be used for other purposes also.


And rating you up for giving many ideas

Quote:Original post by delta user
btw, temporary objects do not allocate memory from the heap. They allocate from the stack.
std::string might internally allocate a buffer but the temporary objects(when concatenating) don't.

quick link

Thanks. I found a new thing. std::string has its internal buffer. Probably will be specific to implementation. In VC2005, std::string has 16-bytes buffer which is allocated on the stack (if the string itself is allocated on the stack, of course) so strings smaller than 16 bytes will not require heap. But it still uses heap if it's larger than 16bytes, even temporary objects.

BTW, I had been pretty sure that it always uses heap. So rating to you for correcting me.

What's this obsession with performance? Are you having an actual performance problem? Or does std::string "just make you sick"?

Rolling your own version of string will likely treat performance (if at all) for other quality factors like correctness (is your own implementation exception safe?).

Quote:
Certainly. But I'm talking about tradeoffs between performace and simplicity. One can get similar performance with std::string by writing tricky code. What's the point of doing that? If you have to seriously consider using "+" overloaded operator, why don't you just sweep away it? And you won't be able to get same performance as strXXX functions since std::string always involves heap operation.

The simplicity of strXXX in this situation comes from dealing with the most trivial requirements: concatenating two short strings with fixed length. If you wanted to concatenate strings of arbitrary length it might become considerably trickier with strXXX functions (you'd have to do practically the same work as std::string to guarantee correctness).

Quote:
Thanks. I found a new thing. std::string has its internal buffer. Probably will be specific to implementation. In VC2005, std::string has 16-bytes buffer which is allocated on the stack (if the string itself is allocated on the stack, of course) so strings smaller than 16 bytes will not require heap. But it still uses heap if it's larger than 16bytes, even temporary objects.

Yes, std::string implementations vary considerably. E.g with MingW sizeof(std::string) is 4 (it's a pimpl class with 1 heap allocation for everything?), with VC++ 2005 it is 28 (contains the small string buffer?), with Comeau Online it appears to be 12, etc.

string's as primatives are not made to be used in the context of multiple small appendations. c++ provides std::stringstream as the established mechanism to do this. likewise NET has stringbuilder and i am sure there is an equivalent in java. i can recommend boost::iostream as well that implements a facade giving you streaming operators like operator << () and doing buffered writing into an stl type container (deque, vector etc).