Boost logo

Boost :

From: Boris Fomitchev (fbp_at_[hidden])
Date: 2000-01-31 15:30:08

"greg colvin" <gcolvi-_at_[hidden]> wrote:
original article:
> What is sad here is how easily Dave could hack up an allocator that is
> way faster than the system defaults. There is no reason, given what
> know about memory allocation, for the system allocator to be any
> than what Dave did, but vendors keep on shipping crap.

shared_ptr does not use allocator<>, it uses new() to allocate longs.
Otherwise, with gcc results would be dramatically different as its
allocator<> uses SGI node allocator which basically does the same trick
linked implementation does, except smallest size of the block would be
I think shared_ptr has to have its own memory pool thouhg, as
linked approach does - to be independent of std:: quality, to use 8x
memory and to move synchronization overhead out of common allocation
> I've sent a (proprietary, belongs to a former employer) fast allocator
> that I wrote to Dave and Gavin to try if they want. If it measures up
> well enough I'll consider boosting it.

That might be another oprion for other components, but I do not see
what could be done for linked implementation presented (except
and moving static data into a member - to keep all in header all that
it takes
is to make it a specialization of some template <bool dummy>


> I think the bottom line remains, until someone shows otherwise, that
> given an adequate allocator there is not very much difference in the
> performance of the various implementations of shared smart pointers.

I also think so - if shared_ptr uses allocator<>. I do not think new()
will ever compare in speed, since it's usually a very general case.


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