Question

I use all over my code std::string objects, most of them stack allocated. I replaced default new/delete operators to check the average memory allocation size and I was surprised to see that most allocations come from std::string and, this is very important, they are between 12 and 32 bytes! To optimize this(large number of small strings allocated from the free storage) I came with a simple solution:

• implement custom string class
• add predefined buffer in it with fixed size, for example 64 bytes(I can adjust this size after profiling)
• use predefined buffer when the length of the string is less than 64 bytes or allocate new buffer from the free storage for larger strings.

With this implementation I will add 64 bytes memory overhead to all my strings with length > 64 add also (64-lenth) overhead to strings shorter than 64 bytes, but I will prevent all the allocations for small strings.

Did you tried such approach? Is it resonable to add this memory overhead, most of the time on the stack to save allocation time/memory fragmentation?

Is this approach better than custom str::string allocators?

Answer 1

Is it reasonable? It depends. Unless you have found yourself actually running out of memory by using std::string or identified a real (as opposed to perceived) performance problem with continued allocation and deallocation, you’re wasting your time doing this.

Don’t get me wrong, you can (and I have) made great gains over standard allocators by using extra information unavailable to them. But, unless there’s a real problem to be fixed, you’re better off using the standard method and devoting your time elsewhere.