Quote Originally Posted by _uj View Post
. I think there's a very good reason why Alexandrescu devotes 20 percent of his much acclaimed Modern C++ Design book to efficient small object allocation and smart pointers.
One has nothing to do with the other. And 18 out of 314 pages is less than 6%. This means that 94% of the book has NOTHING to do will allocatrion. Even that 6% is related specifically to small object allocation, and not allocation in general. Even with in that chapeter the performance is referred to as a "bump in the road" (pg 78) and not as a major issue in the persuit of an efficient C++ program..

I realize my conclussions are based on hearsay and personal experience. Therefore I would wellcome an ambitious investigation from some independent party into how different allocators influence the performance of OO programs. If it turns out that standard (or maybe they should be called general) allocators are good enougth then fair enougth. But until then I prefer an allocator with the outspoken objective of performing well under the OO programming style. That's the "standard" allocator I want. I don't quite understand why there's such an opposition to such a wish. Why would it be so much better if I use the allocator that came with the compiler?
Because (Alexandrescu , Sutter, and Meyers agree) the relevance of this issue is specific to the type of application, the comparision has to be done for specific application.

YOU alread have a set of applications where you have used an alternate allocation.

You should have performance metrics (time and resources) of each application level action. For a GUI application (desktop or Web) this means response times for each possible user action (button click, menu selection, etc.) under a variety of conditions. [A typicall application will have anywhere from a few dozen sample points to a few hundred, and large applications may have a few thousand]. These should all be part of you normal testing process and proceedures.

Take your existing applications and simply disable the replacement allocator (should be commenting out just a few lines) , and re-run the same suite of tests. Compare the numbers as a percentage, relative to the specification for each item.

You will then have a documented case of how many places in your application your replacement allocator allowed you to meet a specification where the default allocator would have caused a failure.

And most importantly, the number will be based on your specific style of writing applications, and therefore likely be applicable to future works.