Some overhead relating to standard library

[Mitsuru]

Dear all,

I think about overhead relating to standard library and language specification when I wrote high performance codes.

If you know the least, I would appreciate it if you could tell me overheads of the below.

(1) Smart pointers (shared_ptr, unique_ptr)

I understand construction and copy of the smart pointer entail some overhead to treat reference counter. But, I find documents about access to them has no overhead (ptr->member, etc).
Sometimes I use Pimpl idiom, and found this leads to overhead due to indirect reference to its substantial pointer, which seems to be the same with smart pointers.
Do they take overhead for the indirect reference?

(2) std::function

To realize strategy-pattern-like dynamical switch of function call, I am fond of std::function. But, I always wonder if they takes some overhead. It is well known that virtual functions entails overhead due to searching vlook-up table. If std::function has less overhead, it is reasonable always to use std::function instead of interfacing to virtual member functions of subclass.
Is there overhead to call std::function?

Probably, it is unclear how much they affect real computing performance in quantitative aspects. As you know the theoretical knowledge or specification of languages, please advise me.

Kind regards,
Mitsuru

[JLBorges]

std::unique_ptr<> with the default deleter std::default_delete<> has zero or near-zero overhead over a raw pointer.

Both std::shared_ptr<> and std::function<> use type erasure; they would have measurable run-time overheads over raw pointers. There is a quality of implementation issue; so you would need to measure performance for your typical use-case on the compiler.library that is used.

[dhayden]

virtual functions entails overhead due to searching vlook-up table

Perhaps I'm mistaken, but I think the only overhead is an extra array access. In other words, a call to virtual function A::vf() is sort of like this pseudocode:

funcPtr = A::vtable[indexOfvf];  // indexOfvf is a constant known at compile time.
funcPtr(this);

And keep in mind that a modern computer can execute those two instructions in about the time that it takes the light that you're reading to travel from your screen to your eye. If your program has performance problems, it's unlikely that they're caused by virtual function overhead.

If I'm wrong, someone please correct me.

Dave

[Cubbi]

vtable overhead is just a subset of general indirection overhead: it's bad when it hits a cold cache line in ways the CPU can't predict and prefetch

[Mitsuru]

Thank you for your detailed replies.

As understood, vtable is a mere indirection overhead, which does not deteriorate performance in modern computers so much.
But, how about type erasure? I have little knowledge about it. As far as I read documents in some HP sites,
it seems that type erasure is some form of delegate via template technique, in which called objects are statically determined in compile time.

Is calling via type erasure more overhead than vtable techniques?

[Mitsuru]

P.S.

As to std::shared_ptr vs raw pointer, I understand that the latter is faster since direct reference to the instance on memory.

[JLBorges]

> Is calling via type erasure more overhead than vtable techniques?

The call through std::function<> and access though std::shared_ptr<> are typically not very expensive.

The more expensive operations are instantiation of, and assignment to, objects of type std::function<> or std::shared_ptr<>.

[Mitsuru]

Dear JLBorges

Thank you for your kind reply.

I understand what you told me, and I am considering alternative use of the pointers based on the performance measurement.
Anyway, I appreciate your helpful comments.

Kind regards,
Mitsuru

[Duthomhas]

@Mitsuru

I am considering alternative use of the pointers based on the performance measurement.

Don't waste your time. Use the nice, fancy C++ features that make your code safe and easy.

Once your program is running, profile it. If using smart pointers is indeed significantly impacting your program, only then should you try to figure out how to fix it.

Measurement = profiling
Measurement ≠ words in an online forum about performance

Hope this helps.

[Mitsuru]

Dear Duthomhas,

Thank you for your advice.

What you meant is understandable. Programming is successive occurrence of trade off, especially between performance and robust design.

I will profile and confirm whether the current status is enough for my purpose.

Sincerely

[Thomas1965]

This might be worth looking at:
http://www.cplusplus.com/forum/lounge/248940/

[Cubbi]

Mitsuru wrote:

vtable is a mere indirection overhead
But, how about type erasure?

It's the same thing: type erasure (in the cases discussed here: std::function's call operator and std::shared_ptr's deleter) is implemented using a vtable call. Step though them in your IDE/editor/debugger and see for yourself. If you are indeed interested in "high performance codes", knowing what you're doing is the basic starting point.

[Mitsuru]

Dear Cubbi

Thank you for your detailed and kind comment.

I believe classical programming (raw pointer, static type, static call) is efficient in the pursuit of "high performance codes".

But, to realize versatile purposes, I would like to rely on modern arts. I wish I could grasp the trade off anytime by knowing what I am doing.