Re: [boost] asio formal review begins

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-12-18 06:07:10

Ion Gaztañaga wrote:
>> 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.

[...]

> Maybe a bit of paranoia, but not all "new" implementations are
> optimized and pooled for small allocations.

They aren't. My point is that the solution is to globally replace ::operator 
new or malloc with one that is, not make every component deal with the 
possibility in its own (incompatible and possibly inferior) way.

BTW, Windows's allocator is far from being one of the best. Good 
general-purpose allocators match quick_allocator in the ST case and run 
circles around it in the MT case. The main reason that it was included is 
contrived "shared_ptr vs ..." benchmarks. For real applications, even 
dlmalloc is better. :-)

> 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.

The CVS version of shared_ptr supports custom allocators.