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

From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2006-10-23 08:32:11

On Mon, October 23, 2006 14:13, Peter Dimov wrote:
> Ovanes Markarian wrote:
>> Hello,
>>
>> we have some application, where boost::shared_ptr is extensively
>> used. After profiling with gprof I got that the shared_ptr destructor
>> is very expensive. I used following g++ compiler flags to compile:
>>
>> -Wall -ftemplate-depth-50 -fexceptions -fexpensive-optimizations -O3
>>
>> Are there may be some MACRO-defs, which can enable/disable some
>> additional optimizations?
>
> First, you need to determine where the time is being spent. Typically,
> ~shared_ptr for the last instance performs two atomic decrements and two
> 'delete p' operations; the first delete calls the destructor of your object,
> the second destroys the control block, and there are two calls to operator
> delete.
>
> What is your platform? You may try to play with #define
> BOOST_SP_USE_QUICK_ALLOCATOR and see if it helps. See
> shared_ptr_alloc_test.cpp for an example. If your application is single
> threaded, you can try BOOST_SP_DISABLE_THREADS (although I don't believe
> that the problem is with the atomics; it's more likely that 'delete' is an
> expensive operation for some reason.)
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>

Peter,

thanks for your reply. Regarding platform etc. I wrote in my parallel post to Vladimir.
Should I define this macros, before installing boost libs or in my app. I assume my app would be
enough, since shared_ptr does not link to any external boost libs.

May I read somewhere about the quick allocator used? I am going to write my own allocator to avoid
heap fragmentation and would like to see, how boost allocator works.

With Kind Regards,

Ovanes Markarian