Re: [Boost-users] [boost::shared_ptr] performance killer

From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2006-10-23 09:42:13

On Mon, October 23, 2006 15:25, Peter Dimov wrote:
> Ovanes Markarian wrote:
>
>> Now with default macros used, shared_ptr is about 10% slower. If I
>> use the quick allocator the speed is only 8% slower. If I enable both
>> macros (single-threaded and quick-allocator) shared_ptr is quicker as
>> an implementation without shared_ptr. My question now would be if you
>> plan or it is already possible to have a policy for specifying
>> Threading and Allocator?
>
> You can override the allocator used for the internal allocation of the
> control block by using the shared_ptr constructor taking three arguments
> (it's a relatively new feature) but judging by the numbers, there isn't much
> point in doing so, as the default allocator is good enough. 2% isn't a
> significant difference and it may well be the case that the default could be
> faster in real code.
>
> Currently there is no way to specify a threading policy.
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>

Well, I have messages consisting from multiple optional smaller object instances. I would like to
try the approach described in A. Alexandrescu's Modern C++ Design: Small Object Allocator.
Unfortunately I can not use it directly from Loki lib, since it does not have interface described
in c++ standard for std::allocator.

I think 2% in such a small piece of software, which constists let's say from ca. 7 such small
pieces can turn out into a 14% perfromance increase if a good allocation strategy can be found.

With Kind Regards,

Ovanes Markarian