Why does libc++'s implementation of std::string take up 3x memory as libstdc++?
Solution 1
Here is a short program to help you explore both kinds of memory usage of std::string
: stack and heap.
#include <string>
#include <new>
#include <cstdio>
#include <cstdlib>
std::size_t allocated = 0;
void* operator new (size_t sz)
{
void* p = std::malloc(sz);
allocated += sz;
return p;
}
void operator delete(void* p) noexcept
{
return std::free(p);
}
int
main()
{
allocated = 0;
std::string s("hi");
std::printf("stack space = %zu, heap space = %zu, capacity = %zu\n",
sizeof(s), allocated, s.capacity());
}
Using http://melpon.org/wandbox/ it is easy to get output for different compiler/lib combinations, for example:
gcc 4.9.1:
stack space = 8, heap space = 27, capacity = 2
gcc 5.0.0:
stack space = 32, heap space = 0, capacity = 15
clang/libc++:
stack space = 24, heap space = 0, capacity = 22
VS-2015:
stack space = 32, heap space = 0, capacity = 15
(the last line is from http://webcompiler.cloudapp.net)
The above output also shows capacity
, which is a measure of how many char
s the string can hold before it has to allocate a new, larger buffer from the heap. For the gcc-5.0, libc++, and VS-2015 implementations, this is a measure of the short string buffer. That is, the size buffer allocated on the stack to hold short strings, thus avoiding the more expensive heap allocation.
It appears that the libc++ implementation has the smallest (stack usage) of the short-string implementations, and yet contains the largest of the short string buffers. And if you count total memory usage (stack + heap), libc++ has the smallest total memory usage for this 2-character string among all 4 of these implementations.
It should be noted that all of these measurements were taken on 64 bit platforms. On 32 bit, the libc++ stack usage will go down to 12, and the small string buffer goes down to 10. I don't know the behavior of the other implementations on 32 bit platforms, but you can use the above code to find out.
Solution 2
You should not be concerned, standard library implementors know what they are doing.
Using the latest code from the GCC subversion trunk libstdc++ gives these numbers:
32 320 344
This is because as of a few weeks ago I switched the default std::string
implementation to use the small-string optimisation (with space for 15 chars) instead of the copy-on-write implementation that you tested with.
Solution 3
Summary: It only looks like libstdc++
uses one char*
. In fact, it allocates more memory.
So, you should not be concerned that Clang's libc++
implementation is memory inefficient.
From the documentation of libstdc++ (under Detailed Description):
A string looks like this:
[_Rep]
_M_length
[basic_string<char_type>] _M_capacity
_M_dataplus _M_refcount
_M_p ----------------> unnamed array of char_type
Where the _M_p points to the first character in the string, and you cast it to a pointer-to-_Rep and subtract 1 to get a pointer to the header.
This approach has the enormous advantage that a string object requires only one allocation. All the ugliness is confined within a single pair of inline functions, which each compile to a single add instruction: _Rep::_M_data(), and string::_M_rep(); and the allocation function which gets a block of raw bytes and with room enough and constructs a _Rep object at the front.
The reason you want _M_data pointing to the character array and not the _Rep is so that the debugger can see the string contents. (Probably we should add a non-inline member to get the _Rep for the debugger to use, so users can check the actual string length.)
So, it just looks like one char*
but that is misleading in terms of memory usage.
Previously libstdc++
basically used this layout:
struct _Rep_base
{
size_type _M_length;
size_type _M_capacity;
_Atomic_word _M_refcount;
};
That is closer to the results from libc++
.
libc++
uses "short string optimization". The exact layout depends on whether _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT
is defined. If it is defined, the data pointer will be word-aligned if the string is short. For details, see the source code.
Short string optimization avoids heap allocations, so it also looks more costly than libstdc++
implementation if you only consider the parts that are allocated on the stack. sizeof(std::string)
only shows the stack usage not the overall memory usage (stack + heap).
Solution 4
I haven't checked the actual implementations in source code, but I remember checking this when I was working on my C++ string library. A 24 byte string implementation is typical. If the length of the string is smaller than or equal to 16 bytes, instead of malloc'ing from the heap, it copies the string into the internal buffer of size 16 bytes. Otherwise, it mallocs and stores the memory address etc. This minor buffering actually helps in terms of running time performance.
For some compilers, there's an option to turn the internal buffer off.
Related videos on Youtube
user4390444
Updated on April 15, 2020Comments
-
user4390444 about 4 years
Consider the following test program:
#include <iostream> #include <string> #include <vector> int main() { std::cout << sizeof(std::string("hi")) << " "; std::string a[10]; std::cout << sizeof(a) << " "; std::vector<std::string> v(10); std::cout << sizeof(v) + sizeof(std::string) * v.capacity() << "\n"; }
Output for
libstdc++
andlibc++
respectively are:8 80 104 24 240 264
As you can see,
libc++
takes 3 times as much memory for a simple program. How does the implementation differ that causes this memory disparity? Do I need to be concerned and how do I workaround it?-
Praetorian over 9 yearsThis is most likely because the libstdc++
std::string
implementation is not C++11 compliant and uses a copy on write implementation which gives you the size savings. Rerun your libstdc++ test usingvstring
instead and compare the results. -
EyasSH over 9 yearsTo be clear, the
sizeof(std::string)
does not represent all the memory occupied by the string, but only the memory occupied by the string class (say, on the stack, for a stack-allocated string), and not any data structures it points to. -
user4390444 over 9 years@EyasSH I have measured. It does allocate 80 bytes and 240 bytes respectively.
-
EyasSH over 9 yearsIs that referring to the array measurement? (because that is not accurate either for the same reason mentioned above).
-
Praetorian over 9 yearsThe results are quite different if you use
__gnu_cxx::__vstring
with libstdc++. And what EyasSH means is that the size of thestd::string
object is not affected by the length of the string it manages. -
M.M over 9 yearsnote that the larger
sizeof(string)
is, the more efficient it is due to small string optimization opportunities! -
underscore_d almost 7 years@Praetorian It is since 2015; phew :)
-
-
Marshall Clow over 9 yearsIn C++11 (and beyond), every use of a shared resource must be thread safe. The heap is a shared resource, and so calls to heap allocation/deallocation routines have to be synchronized. This is (one of) the reason that people want the short string optimization.
-
mostruash over 9 years@MarshallClow Makes sense. Thanks!
-
Marc Glisse over 9 yearsI am surprised that no other implementation played similar tricks as libc++: ensure that "long" and "short" capacities are odd/even, and use all the bytes not containing this crucial bit as a buffer for small strings (except for one byte that holds the length, which is obviously smaller than 256). It does have a cost, almost all operations need to check if the string is short of long before doing anything (though if you do 2 operations in a row it might be able to test just once). Maybe that compensates for the wasted space? Probably depends...
-
Ruslan about 6 yearsOn Ubuntu 14.04 I get the same results from g++ 4.9.4, g++ 5.4.1, and clang++ 3.6.0, all coinciding with your result for gcc 4.9.1.
-
Ilya Popov about 6 years@Ruslan By default they use the same system-installed standard library. You have to provide some flags to use different standard library, for example
-stdlib=libc++
for Clang to use libc++. -
Petr about 6 yearslibc++ always uses SSO, the _LIBCPP_ALTERNATE_STRING_LAYOUT compile-time macro just changes its layout.
-
Philipp Claßen about 6 years@Petr Thank you, I updated it. Also the name of the macro has changed since the answer was written. It is now _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT.
-
FrankHB over 4 yearsThere is surely nothing wrong to make it conforming, but sadly it suddenly becomes significantly suboptimal in a type-erasure wrapper like
any
whose implementation has a slightly smaller internal capacity thansizeof(string)
to do small object optimization... and even worse withpmr::string
.