1

I didn't find information about performance issues with auto_ptr and shared_ptr(I use tr1 implementation). As shared_ptr is more complicated compared to auto_ptr so auto_ptr is faster? So in general question sounds like what can you say about performance of shared_ptr with comparison with auto_ptr?

PS: I know that now unique_ptr is preferable than auto_ptr, but not all compilers support it, so question is about auto_ptr and shared_ptr

Alecs
  • 2,256
  • 8
  • 32
  • 45

4 Answers4

4

  1. When dereferencing there are no performance differences.

  2. If you allocate your shared_ptr's with make_shared you don't waste any heap allocations.

  3. When copying the pointer (not the object), a shared_ptr is a little bit slower because it needs to increase it's reference counter.

However, these probably does not matter, so stick with shared_ptr combined with make_shared.

Viktor Sehr
  • 12,825
  • 5
  • 58
  • 90
  • 1
    `shared_ptr` is greedy, once it grabs hold of a pointer it never let's go (without deleting it), which to me is the most limiting factor. `unique_ptr` or `auto_ptr` can both relinquish ownership and allow the user to select any other type of pointer they may want. – David Rodríguez - dribeas Jun 12 '12 at 14:06
  • I agree with David. `shared_ptr` should not be your default smart pointer. It's heavy and it's forever. – R. Martinho Fernandes Jun 12 '12 at 14:09
  • @David: that's true, but it's not a comparison of the performance of the two. By definition you can only compare the performance of things that they both do. Things that only `auto_ptr` does, and `shared_ptr` doesn't, aren't part of a performance comparison. If the questioner needs facilities that `shared_ptr` doesn't have, then there's worse things wrong with this question than just the risk of somebody advising the use of `shared_ptr` :-) – Steve Jessop Jun 12 '12 at 14:13
  • @SteveJessop: Then the cost of *copying* should also be out of the equation, should it not? – David Rodríguez - dribeas Jun 12 '12 at 14:14
  • @David: heh, maybe. In C++ terms an `auto_ptr` can be copied, via its copy constructor and copy assignment operator. In normal English it's not really a copy, since it modifies the original, but that's standardese for you. – Steve Jessop Jun 12 '12 at 14:15
  • 1
    @R.MartinhoFernandes And it is unreliable---it can't handle cycles (admittedly, `auto_ptr`s way of avoiding them is somewhat brutal), and above all, if you make a `shared_ptr` twice from the same raw pointer, you're in deep trouble. – James Kanze Jun 12 '12 at 15:39
  • @James: if you make an `auto_ptr` twice from the same raw pointer, you're in deep trouble. I can't think of a smart pointer that doesn't have this property. In theory you could create a `shared_ptr` or `unique_ptr` with a do-nothing deleter, in addition to the smart pointer that's actually handling the resource, but in practice I think that'd be a workaround for a broken API, not a genuine example of what you're calling "reliability". – Steve Jessop Jun 12 '12 at 16:39
2

auto_ptr is a deprecated C++98 construct. As such, any performance benefit it might have is far outweighed by the fact that you shouldn't use it anymore in newly-written C++11 code, and instead badger the compiler / library maintainers to implement support for unique_ptr.

That being said, use what semantically fits your use case, unless you have profiled that you have a problem with *_ptr...

DevSolar
  • 67,862
  • 21
  • 134
  • 209
1

In general the only good answer is to measure.

But for this case you know that shared_ptr, unless you're using make_shared it involves a dynamic allocation of a counter block, and unless you have a really good small objects allocator, it's bound to be really slow (talking orders of magnitude) to create the first shared pointer to an object.

But then, perhaps with Boost and the standard library that allocation is really optimized. And maybe, probably!, you can use make_shared to use just 1 allocation for both the object and its control block. So … measure.

By the way, auto_ptr is deprecated.

With any modern compiler use unique_ptr instead.

casperOne
  • 73,706
  • 19
  • 184
  • 253
Cheers and hth. - Alf
  • 142,714
  • 15
  • 209
  • 331
  • Hmmm. It's only been a year since the standard has been adopted. It usually takes compiler writers five or more years for the new features to stabilize to the point where they can be used in production code. I'd says that `auto_ptr` is the way to go for most production code today. – James Kanze Jun 12 '12 at 15:36
  • @JamesKanze I see the practicality of your point, but it *is* the new standard, so why write code using a deprecated function? (It's deprecated in C++11 and people like Stephan Lavavej recommend not using it.) Is `shared_ptr` really *that* experimental? – Chris A. Jun 12 '12 at 15:38
  • Anyway, `shared_ptr` is more-or-less the same as in TR1, which is 6 years old. It's not as though compiler writers were blindsided by its sudden invention, some time in late 2011, and if nothing else the Boost implementation is fine for most production uses. Granted, `unique_ptr` is newer, but it's pretty close to the simplest thing you can do with move semantics that isn't completely pointless. You might like to wait 5 years before using it anyway, depending how cautious you are about the quality of your compiler, but you *can* use it sooner. – Steve Jessop Jun 12 '12 at 16:24
  • Oh, and another option is to implement your own smart pointer which has the same operations as `auto_ptr` and `unique_ptr` (construct, destroy, release, transfer ownership), but which doesn't fixate on `operator=` as the way to transfer ownership, and hence is neither weird like `auto_ptr`, nor reliant on move like `unique_ptr`. Personally I would say that's strictly superior to `auto_ptr`, and hence if you're on an old compiler and dislike `shared_ptr`, do that. – Steve Jessop Jun 12 '12 at 16:35
  • @ChrisA. Because you can't yet write it using the new function, because your compiler doesn't support it, or its support hasn't been validated with sufficient use. (My employer isn't in the compiler testing business.) And deprecated doesn't mean that it will disappear immediately. (I think some of the features deprecated in Fortran 66 are still around.) – James Kanze Jun 12 '12 at 16:40
  • @ChrisA. (and Steve) I'm not too worried about `unique_ptr`---as you say, it's not that new. But to get it, I have to upgrade the compiler, and risk errors in other things. – James Kanze Jun 12 '12 at 16:41
  • @James: yep, that's fair enough. I see why you'd be averse to taking a new compiler, I just got myself puzzled thinking about why you'd avoid this new *feature* in the compiler you have. But that's not what you meant. Oops :-) – Steve Jessop Jun 12 '12 at 16:46
1

As with all performance issues: you need to measure it for yourself in your particular setup.

In general, though, you can expect some more overhead for a shared_ptr<> than for auto_ptr<> as it has to do some more work behind the scene to ensure proper shared behavior for the enclosed pointer.

On the other hand, the two are not really comparable: auto_ptr<> supports only one copy (the ownership is transfered on copy), while shared_ptr<> supports multiple copies. So unless you only use the above pointers for one copy-pointer, you cannot make a meaningful comparision. If you do use one-copy pointer and you are sure you will not need more copies, use the specialized auto_ptr<>.

In any case, whether the performance differences are significant depends on your particular project.

Attila
  • 28,265
  • 3
  • 46
  • 55