[boost] Re: Smart Pointer Timing Test Results

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-01-31 17:34:33

From: Boris Fomitchev <fbp_at_[hidden]>
> "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.

Sorry -- by "system allocator" I meant the "default allocation funtion"
or ::operator new().

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

Sure, but by that argument most every class taht allocates most anything
should have it's own pool.  A high-quality operator new should do the job.

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

I still say most vendor's implementations of new are inexcusably slow,
and I get tired of providing custom allocators for every class just to
avoid calling new.

In the meantime, we can switch to allocator<long> as you suggest.