[go-nuts] efficiency: concrete call versus interface call?

I would recommend measuring 1000+ calls not a single call.
You never know if your system timer precision is up to snuff with your cpu
cycles.
Unless of course you do know that ;)


--

Also turn off any cpu throttling/powersaving features while measuring.

I know that, that's why I measured a million calls :)

--

lol, so you did my bad ;)

--

There's clearly an inlining possibility in your code. Maybe you could
try comparing bytes.Buffer vs io.Reader/io.Writer.

Here the Read/Write methods of bytes.Buffer are not inlined.

Concrete calls have the advantage of being inlined if the method is
very short. When it is not inlined, it is expected that the overhead
is very small (only a couple of instructions).

Rémy.

--

concrete calls versus interface calls in a scenario where the methods
perform more work than just incrementing/decrementing. For the current test
I used such minimal methods to bring the interface call overhead to the
surface as clearly as possible. On my machine, the interface calls take
twice the time of the concrete calls, and something rather vague inside me
tells me this need not be the case, given a compiler that is "smart"
enough. Well, lets hope smartness comes with age, like wisdom is said to
come :)

--

The short answer is that it is not possible to rely on this. A call
through an interface cannot be guaranteed to take the same time as a
direct function/method call, aside through slowing down function
calls.

This is because a direct call to a function can be done as a simple
call to a compile-time known function. A method call through an
interface requires looking up the function to call in a table
referenced by the interface value, then doing a call to it. The former
permits, in many cases, a faster implementation, and never requires a
slower implementation.

You can think, somewhat loosely, of a direct call as equivalent to a
call through an interface for which the compiler has more information
statically available, and so can generate more optimised executable
code. It is equivalent to the difference in C++ between direct
function calls and virtual method calls.

The actual difference may vary with optimisation, as the
implementation could try to convert calls through interfaces to direct
calls when it can statically recognise what type the value in the
interface must be, removing the method lookup and permitting inlining.
I do not believe you will be able to expect this to happen reliably in
the foreseeable future, however.

All that said, unless your functions are doing barely any work, call
overhead should be small, and the additional overhead from the method
lookup even smaller. Both function and interface calls in Go easily
outperform all function calls in languages which require looking up
called functions at runtime, or otherwise don't compile function calls
to a direct call. Such languages may permit functions and methods to
take the same amount of time, but only by making calling both much
slower.

You shouldn't worry about method lookup overhead unless profiling is
directing you to optimise a part of your code, because avoiding it is
likely to have high maintainability costs with near-zero performance
improvement in most places.

--

code would be very suitable for such an optimization.

Agreed.

Sometimes interface methods require just a tiny amount of work, see
the standard library sort interface for example, especially when used
with basic types. Looking up a method and making a call, however
cheap that is, is always more expensive than not doing it, right?

--

...
Yes. Cases like that are where profiling would be more likely to show
improvement, but only if the sorting was itself a significant part of
the larger application's runtime.

It's possible that there will at some point be a defined subset of
possible interface usage which would be specialised like this. I don't
know of any short/middle-term plans for this, but I might have just
not spotted them on the list.

--