Boost logo

Boost :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2005-12-18 05:56:52

> If ::operator new isn't terribly broken (if it is, use dlmalloc), memory
> waste will aready be minimal and allocation would already be fast for small
> objects. Custom per-component allocators are rarely worth the trouble, and
> should never be the default.

In some experiments, I see that for example, in windows, the default
allocator uses pools for small objects, but this is not true in all
systems. For example, in many embedded operating systems (for example,
QNX, eCos, Nucleus... and correct me if someone knows these OS better
than me), there is no optimized new. In these systems, more than speed
problems, you can have fragmentation problems.

The fastest, is of course, avoiding dynamic allocation for small
objects. If we need reference counting, the second one would be to use a
intrusive pointer. Even in windows, you can test your own pool against
"new" and you will see a (very) small speed gain. But if you don't need
multi threaded allocation (some very possible with asio, since from just
one thread you can control all async operations) you can avoid mutexes
in the allocator, the speed gain is noticeable, because the allocation
algorithm in a simple segregated storage is much faster than a mutex lock.

If I were developing a router/rock stable embedded system using asio, I
would prefer controlling the allocations myself, when I know that each
repetitive operations leads to several calls to "new".

Maybe a bit of paranoia, but not all "new" implementations are optimized
and pooled for small allocations. I agree with you that this shouldn't
be default, though. "new" should be default, but I suggest a mechanism
to override this mechanism with user defined allocations. I would love
to see that mechanism in shared_ptr for the counter, because for the
object itself you can use a custom deleter. But this is another history.



Boost list run by bdawes at, gregod at, cpdaniel at, john at