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?

Was it helpful?

Solution

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

OTHER TIPS

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.

One of the purposes of placement new is to use a custom allocator for creating new objects, and calling their constructors. It's not always faster, because it's only as fast as your custom allocator.

Placement new used to place an object at a particular location in memory may take less time, because you actually avoid allocating memory at this step.

However, it must have been allocated at some point before which probably takes time. It makes sense to use it if you actually have a reason to place object at preallocated memory.

It is not a single use of this kind of new operator. More details here.

Also, remember that placement new does not call the destructor automatically! You have to do foo->~Foo(); for your Foo foo; manually.

The only place that I've found where placement new will make your allocations measurably faster is if you have a large number of the same sized objects that have limited lifetimes, causing them to be allocated and destroyed frequently. If you can't guarantee this type of behavior, you're probably better off using the default new implementation.

Applications that need a lot of the same size object can often see a major speed-up from pool (or bulk) allocation. Basically you'd allocate a large buffer (or page) for lots of that object, and then calling placement new within it when the object is requested. While this can speed things up a lot, it's not really necessary for most of programs.

Trying to do this for programs that don't really need it would probably only give you a minimal speedup, but could cost you a lot of hours in debugging.

So really look at what you need; if you're allocating a ton of the same object, yes, placement new could be faster. But just a few objects? I wouldn't bother.

It's not always an issue of time, though. For example, you can use placement new to guarantee alignment of your objects on the heap. You can do something like:

void* buffer = aligned_malloc(sizeof(Object), 16); 
Object* object = new (buffer) Waypoint();

This is necessary for some types, such as float arrays to be used with SSE functions and registers.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top