Bronek Kozicki schrieb:
Peter Dimov <pdimov@mmltd.net> wrote:
Nothing. The implementation of shared_ptr needs a serious redesign WRT thread safety, which is planned but requires free time on my part, which is currently in short supply, although I've got some ordered.
Are there any chance of using reference linking instead of counter allocated on heap,
Not likely. Reference linking offers little advantage in practice over the current implementation, even if we drop the fancy custom deleters and weak pointers to make it look better.
or at least some serious optimization (ie. memory pool) in regard to this heap allocation?
Serious memory allocation optimizations (thread specific pools) require a considerable effort; there's also the problem with thread-specific cleanup on Win32, which requires either a helper DLL, or would tie shared_ptr to Boost.Threads. But depending on your seriousness, you may find the following alternatives helpful: 0. Make sure that your program is allocation-bound, performance wise. 1. Make sure that your compiler doesn't already have a seriously optimized malloc. Many do, and the number is growing. If it does, attempts to "optimize" memory allocations by manually pooling may (and I've seen it happen) actually cause measurable slowdowns. 2. Replace malloc/global new with dlmalloc (or even a commercial alternative). The advantage is that you will automatically optimize every small object allocation in your entire program; remember that every shared_ptr count allocation has a corresponding object allocation. 3. #define BOOST_SP_USE_QUICK_ALLOCATOR. From: "Daniel Krügler"
Reference linking is really great stuff in (single-thread) theory, but unfortunatly it seems to have lots of difficulties in mt world.
Right, that too.