[smart_ptr] make_shared performance
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been doing a little benchmarking (trivial benchmark program attached) of boost::make_shared performance. With svn trunk, I don't see much improvement from using make_shared, in fact for large objects it is much slower. I would guess this is due to the increased overhead of copying sp_ms_deleter for large types. I wonder if anyone has any ideas for improving the situation? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJcP7d5vihyNWuA4URApVPAJ9EfS6MtkNHTUgb/gOTD/nRngPiUQCeL6K0 MtkmtRAmzKlN1m0eXO9t5k0= =LpQ1 -----END PGP SIGNATURE-----
On Fri, Jan 16, 2009 at 1:40 PM, Frank Mori Hess <frank.hess@nist.gov> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I've been doing a little benchmarking (trivial benchmark program attached) of boost::make_shared performance. With svn trunk, I don't see much improvement from using make_shared, in fact for large objects it is much slower. I would guess this is due to the increased overhead of copying sp_ms_deleter for large types. I wonder if anyone has any ideas for improving the situation?
Benchmarks alone don't mean much without understanding your use case. What are you trying to do, for which boost::make_shared's performance is inadequate? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 16 January 2009 16:46 pm, Emil Dotchevski wrote:
Benchmarks alone don't mean much without understanding your use case. What are you trying to do, for which boost::make_shared's performance is inadequate?
Nothing, actually. I was writing some similar code and based it on boost/make_shared.hpp. I simply became curious if make_shared really was any faster than using the shared_ptr constructors and new. Normally, I try not to be an optimization nut, but from n2351, it is clear that performance optimization is a significant part of the rationale for make_shared existing. To quote n2351: "Besides convenience and style, such a function is also exception safe and considerably faster because it can use a single allocation for the object and its corresponding control block, eliminating a significant portion of shared_ptr's construction overhead. This function eliminates one of the major efficiency complaints about shared_ptr." So it seems reasonable to expect boost::make_shared to provide some observable performance benefit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJcQo85vihyNWuA4URAp5EAKDTvh71HzwrPRyNI5v4ChC2GNgGNgCg3CDP ZMWIDAkFVYTae6uDduFEiHo= =+ohB -----END PGP SIGNATURE-----
On Friday 16 January 2009 16:40, Frank Mori Hess wrote:
I've been doing a little benchmarking (trivial benchmark program attached) of boost::make_shared performance. With svn trunk, I don't see much improvement from using make_shared, in fact for large objects it is much slower. I would guess this is due to the increased overhead of copying sp_ms_deleter for large types.
The attached patch to boost/make_shared.hpp adds an optimized copy constructor to sp_ms_deleter which reduces overhead for large types. It improves the running time of the benchmark I posted before from 13+ seconds on my computer to 3+ seconds. The sp_ms_deleter still gets copy constructed 3 times during a make_shared call, which can probably be reduced.
participants (3)
-
Emil Dotchevski -
Frank Mori Hess -
Frank Mori Hess