Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualMatt-D

Posted 24 July 2012 - 10:44 AM

Overhead of which feature?
Since std::shared_ptr is a thread-safe (TS) reference-counted (RC) smart pointer, you can compare to non-thread-safe reference-counted smart pointer to measure TS overhead -- in this case "For the 8 thread version the mean of the two runs differed by a factor of 2.3 in favour of counted_ptr. "
http://nerds-central...issues-and.html

If you don't need reference-counting, you should obviously be using std::unique_ptr which doesn't have either overhead:
"For the sorting benchmark demonstrated in this article shared_ptr is about 10% slower than unique_ptr. As for size, while the size of unique_ptr is exactly the size of a raw pointer, shared_ptr is about twice as large."
http://eli.thegreenp...ary-containers/

"The first question you'd ask yourself is probably: "Why do I need to learn how to use another smart pointer class when shared_ptr fits the bill?" In one word: performance. shared_ptr uses reference counting to allow the sharing of a single resource by multiple objects. Additionally, its destructor and other member functions are virtual. These properties facilitate the customization of shared_ptr. However, the size of a typical shared_ptr object is 40 bytes, which is 10 times bigger than the size of a raw pointer on a 32-bit platform. The presence of virtual member functions means that in many cases, calls to member functions are resolved dynamically, incurring additional runtime overhead. These issues may not concern you if you're using shared_ptr sporadically. However, in time critical apps, or if you have containers that store a large number of shared_ptr objects, the performance overhead might be overwhelming. unique_ptr gives you a safe and reliable smart pointer alternative that can compete with the size and speed of raw pointers."
http://www.codeguru....tduniqueptr.htm

See also: http://www.codesynth...ed-ptr-counter/

With that said, instead of worrying about overhead it's better to just use the right pointer for the right job :-)

As http://herbsutter.com/gotw/_104/ states: "unique_ptr by default, or a shared_ptr if ownership is to be shared."

#3Matt-D

Posted 24 July 2012 - 10:43 AM

Overhead of what feature?
Since std::shared_ptr is a thread-safe (TS) reference-counted (RC) smart pointer, you can compare to non-thread-safe reference-counted smart pointer to measure TS overhead -- in this case "For the 8 thread version the mean of the two runs differed by a factor of 2.3 in favour of counted_ptr. "
http://nerds-central...issues-and.html

If you don't need reference-counting, you should obviously be using std::unique_ptr which doesn't have either overhead:
"For the sorting benchmark demonstrated in this article shared_ptr is about 10% slower than unique_ptr. As for size, while the size of unique_ptr is exactly the size of a raw pointer, shared_ptr is about twice as large."
http://eli.thegreenp...ary-containers/

"The first question you'd ask yourself is probably: "Why do I need to learn how to use another smart pointer class when shared_ptr fits the bill?" In one word: performance. shared_ptr uses reference counting to allow the sharing of a single resource by multiple objects. Additionally, its destructor and other member functions are virtual. These properties facilitate the customization of shared_ptr. However, the size of a typical shared_ptr object is 40 bytes, which is 10 times bigger than the size of a raw pointer on a 32-bit platform. The presence of virtual member functions means that in many cases, calls to member functions are resolved dynamically, incurring additional runtime overhead. These issues may not concern you if you're using shared_ptr sporadically. However, in time critical apps, or if you have containers that store a large number of shared_ptr objects, the performance overhead might be overwhelming. unique_ptr gives you a safe and reliable smart pointer alternative that can compete with the size and speed of raw pointers."
http://www.codeguru....tduniqueptr.htm

See also: http://www.codesynth...ed-ptr-counter/

With that said, instead of worrying about overhead it's better to just use the right pointer for the right job :-)

As http://herbsutter.com/gotw/_104/ states: "unique_ptr by default, or a shared_ptr if ownership is to be shared."

#2Matt-D

Posted 24 July 2012 - 10:42 AM

Overhead of what feature?
Since std::shared_ptr is a thread-safe (TS) reference-counted (RC) smart pointer, you can compare to non-thread-safe reference-counted smart pointer to measure TS overhead -- in this case "For the 8 thread version the mean of the two runs differed by a factor of 2.3 in favour of counted_ptr. "
http://nerds-central...issues-and.html

If you don't need reference-counting, you should obviously be using std::unique_ptr which doesn't have either overhead:
"For the sorting benchmark demonstrated in this article shared_ptr is about 10% slower than unique_ptr. As for size, while the size of unique_ptr is exactly the size of a raw pointer, shared_ptr is about twice as large."
http://eli.thegreenp...ary-containers/

"The first question you'd ask yourself is probably: "Why do I need to learn how to use another smart pointer class when shared_ptr fits the bill?" In one word: performance. Shared_ptr uses reference counting to allow the sharing of a single resource by multiple objects. Additionally, its destructor and other member functions are virtual. These properties facilitate the customization of shared_ptr. However, the size of a typical shared_ptr object is 40 bytes, which is 10 times bigger than the size of a raw pointer on a 32-bit platform. The presence of virtual member functions means that in many cases, calls to member functions are resolved dynamically, incurring additional runtime overhead. These issues may not concern you if you're using shared_ptr sporadically. However, in time critical apps, or if you have containers that store a large number of shared_ptr objects, the performance overhead might be overwhelming. unique_ptr gives you a safe and reliable smart pointer alternative that can compete with the size and speed of raw pointers. Here's how it's used."
http://www.codeguru....tduniqueptr.htm

See also: http://www.codesynth...ed-ptr-counter/

With that said, instead of worrying about overhead it's better to just use the right pointer for the right job :-)

As http://herbsutter.com/gotw/_104/ states: "unique_ptr by default, or a shared_ptr if ownership is to be shared."

#1Matt-D

Posted 24 July 2012 - 10:41 AM

Overhead of what feature?
Since std::shared_ptr is a thread-safe (TS) reference-counted (RC) smart pointer, you can compare to non-thread-safe reference-counted smart pointer to measure TS overhead -- in this case "For the 8 thread version the mean of the two runs differed by a factor of 2.3 in favour of counted_ptr. "
http://nerds-central.blogspot.com/2012/03/sharedptr-performance-issues-and.html

If you don't need reference-counting, you should obviously be using std::unique_ptr which doesn't have either the TS nor the RC overhead:
"For the sorting benchmark demonstrated in this article shared_ptr is about 10% slower than unique_ptr. As for size, while the size of unique_ptr is exactly the size of a raw pointer, shared_ptr is about twice as large."
http://eli.thegreenplace.net/2012/06/20/c11-using-unique_ptr-with-standard-library-containers/

"The first question you'd ask yourself is probably: "Why do I need to learn how to use another smart pointer class when shared_ptr fits the bill?" In one word: performance. Shared_ptr uses reference counting to allow the sharing of a single resource by multiple objects. Additionally, its destructor and other member functions are virtual. These properties facilitate the customization of shared_ptr. However, the size of a typical shared_ptr object is 40 bytes, which is 10 times bigger than the size of a raw pointer on a 32-bit platform. The presence of virtual member functions means that in many cases, calls to member functions are resolved dynamically, incurring additional runtime overhead. These issues may not concern you if you're using shared_ptr sporadically. However, in time critical apps, or if you have containers that store a large number of shared_ptr objects, the performance overhead might be overwhelming. unique_ptr gives you a safe and reliable smart pointer alternative that can compete with the size and speed of raw pointers. Here's how it's used."
http://www.codeguru.com/cpp/article.php/c17775/The-Smart-Pointer-That-Makes-Your-C-Applications-Safer--stduniqueptr.htm

See also: http://www.codesynthesis.com/~boris/blog/2009/01/11/shared-ptr-counter/

With that said, instead of worrying about overhead it's better to just use the right pointer for the right job :-)

As http://herbsutter.com/gotw/_104/ states: "unique_ptr by default, or a shared_ptr if ownership is to be shared."

PARTNERS