Why should I use placement new?

Question

As it seems, placement new creates a new object on a preallocated memory, so does it mean that it would take less time? Looks like it's faster then allocating using the old ordinary new. Then, if this is so convenient and faster, why not use placement new all the time?

Answer 1

the normal (nonplacement) new is basically equivalent to doing

T* ptr = static_cast<T*>(malloc(sizeof(T)));
new(ptr) T;

Of course the reality looks a bit different due to errorchecking and such, but the result is more or less the same (through not identical, you can't delete a pointer allocated that way, instead you need to call the destructor explicitely (ptr->~T()) and then release the memory using free).

So placement new should indeed be faster then non placement new, since it doesn't need to allocate the memory. However the problem is that the memory needs to be allocated somewhere. So you have essentially replaced one call to new with a call to placement new and some code for the allocation somewhere (if not why would you use new in the first place?). It should be obvious that this is less convinient and more bug prone.

Now of course you can write a faster allocation method, but for that you typically need to do some sort of tradeoff. It's not going to be easy to write a allocator which is faster without either using more memory (extra data for faster identification of free blocks) or making it very specific (writing fast allocation of a single objectsize is much easier then a general one). In the end it is typically not worth the effort (for scenarious where it is worth the effort it has likely already been done, so you could use an existing allocator (which likely uses placement new internally)).

There are of course uses for placement new (sometimes you do have the memory preallocated), but that is simply not the common case

Answer 2

It is simply unnecessary for most programs as their usage patterns don't make it necessary. It makes no difference for programs that don't use the heap as much and it is hard to get right (better than your operating system, that is). Also can you only gain so much by optimizing your allocation. For the most part any algorithmic optimization is going to result in a much larger over-all speed-up. A lot of the guarantees that a customized allocator can offer (guaranteed time limits for allocation through pre-allocated memory, low memory fragmentation) are often not needed.

There are definitely programs that can benefit from doing memory-managment themselves, they are just hard to identify. After you have found that memory-allocation is actually a bottle-neck it is even harder to find a better allocation scheme. When all that is done, it is still not often worth the hassle.