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

From: Leon Mlakar (leon.mlakar_at_[hidden])
Date: 2006-10-23 09:54:48

> -----Original Message-----
> From: boost-users-bounces_at_[hidden] 
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Peter Dimov
> Sent: Monday, October 23, 2006 3:25 PM
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] [boost::shared_ptr] performance killer
> 
> 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.
> 

It's not in 1.33.1, is it? It may not bring performance benefits, still, it
is a usefull feature to have.

I recently worked with a real-time system that offered several heaps to
allocate from, ranging from the block private to the system shared. Having
the shared count allocated from a different heap than the object it guards
is usually not a good idea in such systems.

Best regards,

Leon Mlakar