-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: Monday, October 23, 2006 3:25 PM To: boost-users@lists.boost.org 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