[boost] Re: Smart Pointer Timing Test Results

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

"greg colvin" <gcolvi-_at_[hidden]> wrote: 
original article:http://www.egroups.com/group/boost/?start=2034
> 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
we
> know about memory allocation, for the system allocator to be any
slower
> 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
8.
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
less
memory and to move synchronization overhead out of common allocation
bottleneck.
 
> 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
synchronization
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>

-Boris.

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

-Boris.