Subject: Re: [boost] [Smart Ptr] make_shared slower than shared_ptr(new) on VC++9 (and 10) with fix
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2012-04-26 02:12:20
[STL]
> Each is optimally sized (in particular, make_shared/allocate_shared
> implement the "we know where you live" optimization that I have
> previously described
[Dave Abrahams]
> I can't find that description. Pointer please?
See http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/STL11-Magic-Secrets (which also has links to my slides - viewable online even without PowerPoint), in particular Slide 6. I described the optimization in detail, but without code, so you can pick it up without reading my sources. Basically, the "traditional" control blocks need to keep a pointer to the object so they can delete it (because of conversions, the shared_ptr's own pointer cannot be used for this purpose - it could have the wrong address with no way to restore it at runtime). But if you're willing to write dedicated control blocks for make_shared/allocate_shared (instead of trying to stuff the object in a special "deleter"), then they can just destroy the object in place. "We know where you live", so we don't need to store a pointer to the object.
I was surprised when I learned that I was apparently the first one to implement this - I just assumed that everyone would write it this way. See slide 7 for measurements - picking up this optimization should save you 8 bytes on x86 and 16 bytes (!!!) on x64. That's per object, so if you have a lot of them, it adds up.
Consider it a gift - my thanks for all of the wonderful things that Boost has given TR1/C++11.
> You don't need a special case for emptiness if you make them base
> classes when they're classes (a.k.a. use boost::compressed_pair)
I should look into implementing that from scratch in VC12. Sometimes I dream about making the STL dependent on Boost, and causing the universe to recursively implode. It would be fun!
STL