Performance using member of

[Lilith]

If I have a class object and a pointer to the object is there a
performance hit for invoking a member function using member of (.) vs
member of (->) due to pointer arithmetic? From an amateur point of
view I'd initially think that the pointer arithmetic would cause a
slow down. On the other hand pointer arithmetic shouldn't even be an
issue since the member functions aren't actually part of the object
but instead a member of the class.

Please advise.

 

[TB]

Lilith sade:

If I have a class object and a pointer to the object is there a
performance hit for invoking a member function using member of (.) vs
member of (->) due to pointer arithmetic? From an amateur point of
view I'd initially think that the pointer arithmetic would cause a
slow down. On the other hand pointer arithmetic shouldn't even be an
issue since the member functions aren't actually part of the object
but instead a member of the class.

Please advise.

Slow down? Do you expect a noticable performance decay?
No difference of any vital concern. Don't bother
reflecting upon it.

 

[Mike Wahler]

If I have a class object and a pointer to the object is there a
performance hit for invoking a member function using member of (.) vs
member of (->) due to pointer arithmetic? From an amateur point of
view I'd initially think that the pointer arithmetic would cause a
slow down. On the other hand pointer arithmetic shouldn't even be an
issue since the member functions aren't actually part of the object
but instead a member of the class.

Write your code so as to be as simple and easily
readable as possible. Only worry about performance
if you can *prove* it's an issue (by measurement).

I strongly doubt you'll see a measurable difference
between using '.' operator vs '->' operator.

-Mike

 

[Bob Hairgrove]

If I have a class object and a pointer to the object is there a
performance hit for invoking a member function using member of (.) vs
member of (->) due to pointer arithmetic? From an amateur point of
view I'd initially think that the pointer arithmetic would cause a
slow down. On the other hand pointer arithmetic shouldn't even be an
issue since the member functions aren't actually part of the object
but instead a member of the class.

Please advise.

You are correct when you say that pointer arithmetic shouldn't be an
issue. The physical address of a particular non-static member function
should be the same whether one calls it on an object or on a pointer.
It should be actually the same for all objects of the same class ...
if anything, calling through a pointer (i.e. with -> syntax) is
conceivably faster than with the dot operator because each member
function gets passed a hidden argument: the "this" pointer of the
object involved. Since the pointer already contains that address, it
shouldn't have to be "looked up" or calculated with some kind of
pointer arithmetic.

But if you think about how the machine code generated by the compiler
would have to be seen by the CPU, ask yourself: What is an "object"?
According to most definitions of an object, it is an area of storage
with a certain structure as determined by the class declaration. But
any area of storage at that low level would have to be accessed
through memory addresses, IOW pointers. The only difference is that a
pointer occupies storage of its own, but every compiler is "smart
enough" to be able to optimize away that one level of indirection
under most circumstances.