[grundprinzip]

I think there is something missing in the discussion of the article: Shared pointers are used for shared ownership, where in the example the author is assuming unique ownership.

In the benchmark this requires the compiler to generate code that makes sure that the object was not changed by issuing an exclusive request for the data plus the additional pointer dereferencing.

To check what is really happening I recommend two things:

1) Look at the generated code and see what the compiler issues. 2) Compare object* vs shared_ptr<object> 3) Compare unique_ptr vs object vs object*

My assumption is that unique_ptr will be faster than shared_ptr and have the same speed as object* and that will be a bit slower than object.

[ah-]

You're completely right about shared_ptr not being the right tool for this use case.

However, I haven't tried it but just looked up the implementation of std::shared_ptr in GCC 4.9.0, and accessing it is exactly the same as with a raw pointer. operator-> and operator* just return the internal pointer and do nothing else.

There's some slight space overhead associated with shared_ptr, since it has to store the two counters for shared and weak references, so that might influence the runtime. unique_ptr should behave exactly like a raw pointer.

That said, I'd love to see some benchmarks about this as well and would be even happier to be proven wrong.

Another aspect I find interesting about this is that as the objects grow, it makes sense to store them in column-wise (one array/chunk of memory just for member1, one for member2, ...) instead of row-wise.

I don't know any languages besides Q that make this way of storing data easy/the default.

[geophile]

I thought that the main point of the article was about memory locality. If that is so, then the kind of pointer (auto vs. shared) is a distraction, isn't it? (My experiment was intended to be about locality only.)