"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes: > > > Lock mechanism was added to shifted_ptr<>: > > http://groups.yahoo.com/group/boost/files/shifted_ptr.zip > > > > Benchmarks are also updated. Still shifted_ptr<> is using less memory and > > twice faster for reconstruction time. > > Almost.
benchmark-nothreads.txt is more precise than benchmark-yesthreads.txt because there is no switching between threads. But yes it is almost doubled (90%). > > Notes: > > - The first memory map report is not precise (shifted_ptr<U>). > > - The reports were reordered (shifted_ptr<U>, shifted_ptr<T> & > > shared_ptr<T>). > > > > I believe there is not that much left to do besides optimizations. > > Have you tried a comparison against a shared_ptr using an optimized > count allocator? Nobody has invested as much effort in optimizing > shared_ptr as you are pouring into shifted_ptr, but an experiment I > did years ago made a huge difference in the efficiency of shared_ptr > just by implementing a crude allocator for count objects (took me > about 10 minutes to code up). For me to find shifted_ptr convincing > I'd have to see a noticeable performance improvement over using an > optimized count allocator with shared_ptr. I think the best way to optimize counts using shared_ptr<> is to derive the subject class from counted_base. This way shared_ptr<> should logically be exactly like shifted_ptr<> in terms of CPU cycles and memory usages. But you won't be able to use typenames easily and complex hierarchies will highly likely confront ambiguity for multiple ownership if virtual inheritance is not used. It is just another solution involving different costs / benefits. Regards, Philippe A. Bouchard _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
