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
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>
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk