Adap.TV has chosen C++ to develop their software. However, they’ve decided not to use the standard containers1 and boost for performance reasons, as they’ve blogged about it in the following article:
- Why we use C++ (without using STL or boost)
It says (emphasis mine),
There are several rules that we are obeying in order to keep the performance high;
Avoid malloc(), calloc() or new
No free() or delete (and no need for tcmalloc)
No STL, boost etc.
Avoid locking as much as possible
# threads = # CPU cores (hyperthread is a trade-off between latency and throughput)
As we know, the standard containers use allocators which uses new and delete internally which are expensive operations. So to avoid them, AdapTv has avoided using standard containers altogether. Instead of using new and delete (repeatedly), they reuse memory (which implies they use a memory pool).
I’m wondering what’s stopping them from using custom allocators for the standard containers! The custom allocator could use a memory pool internally which means memory reuse. So I don’t see how standard containers would hurt performance.
Or am I missing something? Can’t we avoid using new and delete with standard containers? Is there any other reason why would anyone avoid using standard containers? Or is it simply a lack of knowledge on their part which led to this decision?
And how about boost?
1) I suppose by STL they meant C++ standard containers, not SGI’s STL.
19
Obviously malloc() and free() reuse memory, from the “pool” of your available RAM plus swap. However, in the interest of making efficient use of resources, they make a number of trade offs for general purpose computing. The glibc source and this article they reference discuss the trade offs in pretty good detail.
The most prominent trade off is time-space. Essentially, if you want your allocator to be faster, you are going to end up wasting some space. Pre-allocating a memory pool is an example of wasting space, since you have to allocate as much memory as you think you will ever need. In a single-purpose computer like a server, that trade off is acceptable. You’re not going to want that memory for another application.
If you use STL custom allocators, you get control over where the memory comes from, but you still can’t control when and how often the allocator is called. Every once in a while, you unavoidably take a big hit, like needing to defragment. You also usually need locking. They are avoiding that problem altogether, at the expense of wasting some memory. Wasting is probably the wrong word though, since it’s a deliberate choice. You’re investing the memory to gain speed.
As a side note, it also happens to increase reliability. I used to work somewhere with a prohibition on dynamically allocated memory, but not for performance reasons. If all your memory is allocated at the beginning, you can easily determine your maximum memory requirements, and know a burst won’t put you over your physical limit.
1