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:

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.

closed as not constructive by Robert Harvey, Michael Kohne, user40980, Martijn Pieters, Martin York Apr 1 '13 at 23:20

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Boost I can see because some of the libraries can get pretty complicated, but nowadays there's no reason to avoid the STL, unless you're doing embedded programming I suppose. – bstamour Apr 1 '13 at 18:09
  • 9
    When someone says to me that he does not want to use standard XYZ "for performance reasons", I translate this as "I love reinventing the wheel". – dasblinkenlight Apr 1 '13 at 18:11
  • 1
    Can you point out ten differences between "reusing memory" and "rolling your own malloc"? I mean, lookaside lists are good and everything, but really, what else is there? – dasblinkenlight Apr 1 '13 at 18:13
  • 2
    @zxcdw: No true. There will be one call to the OS for every billion (exaggerated) call to new. The application gets pages at a time from the OS. Then manages those pages internally. That management of the pages is very efficient. So most of the time new/delete are efficient and basically involve swapping a few pointers. – Martin York Apr 1 '13 at 18:19
  • 2
    @Nawaz: I have no idea. But that emphasis my point. To think that is not even thinkable that Java is comparable is a silly point to start from. They are comparable and they should have done so. Personally I dislike Java (for other reasons) but if I was starting a new project from scratch and had the choice of languages (rare at the best of times) then I would have done some testing to see if they comparable and how they did for all metrics that were important. A blanket statement (without data) is worth less than a blanket. – Martin York Apr 1 '13 at 20:11

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, as that indeed seems to be their approach: tying up large blocks of memory for personal consumption. – Robert Harvey Apr 1 '13 at 21:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.