Re: [boost] asio formal review begins

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.

Regards,

Ion