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@lists.boost.org 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