Skip to content
This repository has been archived by the owner on Feb 8, 2018. It is now read-only.

teh-cmc/interface-bench

Repository files navigation

Interface-Bench

A quick look at some of Go's subtleties regarding the use of interfaces and the performance issues that might ensue.

Table of Contents

Round I: Method calls on concrete types vs. interfaces

Let's compare the performances of doing 100 million method calls on a concrete type (int64) vs. an interface.
The code is as follows:

package main

import (
	"fmt"
	"time"

	"github.com/pkg/profile"
)

// -----------------------------------------------------------------------------

// Int provides an `int64` that implements the `Summable` interface.
type Int int64

// Sum simply adds two `Int`s.
func (i Int) Sum(i2 Int) Int { return i + i2 }

type Summable interface {
	Sum(i Int) Int
}

// -----------------------------------------------------------------------------

const nbOps int = 1e8

func main() {
	defer profile.Start(profile.CPUProfile).Stop()

	var start time.Time

	var iConcrete Int
	start = time.Now()
	for i := 0; i < nbOps; i++ {
		iConcrete = iConcrete.Sum(Int(10))
	}
	_ = iConcrete
	fmt.Printf("[concrete]  computed %d sums in %v\n", nbOps, time.Now().Sub(start))

	var iInterface Summable = Int(0)
	start = time.Now()
	for i := 0; i < nbOps; i++ {
		iInterface = iInterface.Sum(Int(10))
	}
	_ = iInterface
	fmt.Printf("[interface] computed %d sums in %v\n", nbOps, time.Now().Sub(start))
}

Pretty straightforward stuff. The results look like these:

$ go version
go version go1.6.2 darwin/amd64
$ sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
$ go run concrete_vs_interface.go
[concrete]  computed 100000000 sums in 41.966579ms
[interface] computed 100000000 sums in 2.799456753s

At first glance, it would seem that going through the interface dispatch machinery comes with a terrifying 6500% slow-down... and, indeed, that's what I thought at first; until @twotwotwo rightfully demonstrated how completely broken my benchmark actually was.

So, what is really going on here?
For a concise answer, have a look at #1. If you're looking for the long version, you may continue reading below.

Why are the concrete calls this fast?

100 million calls to a Sum method in 42ms, that's a staggering ~2.4 billion sums per second. Anyway you look at it, that's real fast.

There are two main reasons behind this speed.

1. inlining

Using the -m gcflag will show that the compiler is inlining the call to iConcrete.Sum(Int(10)):

$ go run -gcflags '-m' main.go
# command-line-arguments
./main.go:16: can inline Int.Sum
./main.go:34: inlining call to Int.Sum
...(rest omitted)...

This obviously avoids a lot of copying. Running the same code with inlining disabled (via the -l gcflag) shows a 10x drop in performance:

$ go run -gcflags '-l' main.go
[concrete]  computed 100000000 sums in 413.927641ms

2. no escaping

There are no pointers involved in this snippet, no variables escaping from the stack either; and with Sum being inlined, everything is literally happening within the same stack-frame: there is simply no work at all to be done by the memory allocator nor the garbage collector.

Go code can't go much faster than this.

Why are the interface calls this slow?

100 million calls in 2800ms (~35.5 million per sec), on the other hand, seems particularly slow.

As @twotwotwo mentioned in #1, this slow-down stems from a change that shipped with the 1.4 release of the Go runtime:

The implementation of interface values has been modified. In earlier releases, the interface contained a word that was either a pointer or a one-word scalar value, depending on the type of the concrete object stored. This implementation was problematical for the garbage collector, so as of 1.4 interface values always hold a pointer. In running programs, most interface values were pointers anyway, so the effect is minimal, but programs that store integers (for example) in interfaces will see more allocations.

Because of this, every time iInterface.Sum(Int(10)) returns a result and assigns it to iInterface, sizeof(Int) bytes have to be allocated on the heap and the value of the current variable has to be copied to that new location.

This obviously induces a huge amount of work; and, indeed, a pprof trace shows that most of the time is spent allocating bytes and copying values as part of the process of converting types to interfaces (i.e. runtime.convT2I):

  flat  flat%   sum%        cum   cum%
 740ms 28.24% 28.24%     1180ms 45.04%  runtime.mallocgc
 340ms 12.98% 41.22%     1520ms 58.02%  runtime.newobject
 270ms 10.31% 51.53%      270ms 10.31%  runtime.mach_semaphore_signal
 260ms  9.92% 61.45%     2490ms 95.04%  main.main
 220ms  8.40% 69.85%     2090ms 79.77%  runtime.convT2I
 180ms  6.87% 76.72%      180ms  6.87%  runtime.memmove
 150ms  5.73% 82.44%      330ms 12.60%  runtime.typedmemmove
 130ms  4.96% 87.40%      130ms  4.96%  main.(*Int).Sum
 100ms  3.82% 91.22%      100ms  3.82%  runtime.prefetchnta
  80ms  3.05% 94.27%       80ms  3.05%  runtime.(*mspan).sweep.func1

Note that GC/STW latencies are not even part of the equation here: if you try running this program with the GC disabled (GOGC=off), you should get the exact same results (with Go 1.6+ at least).

So, how can we fix this?

Round II: Pointers

An idea that naturally comes to mind when trying to reduce copying is to use pointers.
The code is as follows:

package main

import (
	"fmt"
	"time"

	"github.com/pkg/profile"
)

// -----------------------------------------------------------------------------

// Int provides an `int64` that implements the `Summable` interface.
type Int int64

// Sum simply adds two `Int`s.
func (i *Int) Sum(i2 Int) *Int { *i += i2; return i }

type Summable interface {
	Sum(i Int) *Int
}

// -----------------------------------------------------------------------------

const nbOps int = 1e8

func main() {
	defer profile.Start(profile.CPUProfile).Stop()

	var start time.Time
	var zero Int

	var iConcrete *Int = &zero
	start = time.Now()
	for i := 0; i < nbOps; i++ {
		iConcrete = iConcrete.Sum(Int(10))
	}
	_ = iConcrete
	fmt.Printf("[concrete]  computed %d sums in %v\n", nbOps, time.Now().Sub(start))

	var iInterface Summable = &zero
	start = time.Now()
	for i := 0; i < nbOps; i++ {
		iInterface = iInterface.Sum(Int(10))
	}
	_ = iInterface
	fmt.Printf("[interface] computed %d sums in %v\n", nbOps, time.Now().Sub(start))
}

The code is almost the same, except that Sum now applies to a pointer and returns that same pointer as a result.

The results look like these:

$ go version
go version go1.6.2 darwin/amd64
$ sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
$ go run concrete_vs_interface_pointers.go
[concrete]  computed 100000000 sums in 178.189757ms
[interface] computed 100000000 sums in 593.659837ms

4x slower concrete calls

The reason for this slow-down is simply the overhead of dereferencing the iConcrete pointer for each summation.

Not much more we can do here.

5x faster interface calls

The reason for this speed-up is that we've completely removed the need to allocate sizeof(Int) on the heap and copy values around every time we assign the return value of Sum to iInterface.

A quick look at the pprof trace will confirm our thoughts:

  flat  flat%   sum%        cum   cum%
 280ms 56.00% 56.00%      280ms 56.00%  main.(*Int).Sum
 150ms 30.00% 86.00%      430ms 86.00%  main.main
  70ms 14.00%   100%       70ms 14.00%  runtime.usleep
     0     0%   100%      430ms 86.00%  runtime.goexit
     0     0%   100%      430ms 86.00%  runtime.main
     0     0%   100%       70ms 14.00%  runtime.mstart
     0     0%   100%       70ms 14.00%  runtime.mstart1
     0     0%   100%       70ms 14.00%  runtime.sysmon

There is effectively no trace of runtime.mallocgc, runtime.convT2I or anything else that's part of the process of converting types to interfaces (T2I) here.

This is still 3-4x slower than concrete calls though; can we make it even faster?

Round III: In-place

Since we're now applying Sum to a pointer, we might as well not return anything.
This will make some nice chaining patterns impossible but, on the other hand, should entirely remove the overhead of creating an interface every time we assign the return value of Sum to iInterface.
The code is as follows:

package main

import (
	"fmt"
	"time"

	"github.com/pkg/profile"
)

// -----------------------------------------------------------------------------

// Int provides an `int64` that implements the `Summable` interface.
type Int int64

// Sum simply adds two `Int`s.
func (i *Int) Sum(i2 Int) { *i += i2 }

type Summable interface {
	Sum(i Int)
}

// -----------------------------------------------------------------------------

const nbOps int = 1e8

func main() {
	defer profile.Start(profile.CPUProfile).Stop()

	var start time.Time
	var zero Int

	var iConcrete *Int = &zero
	start = time.Now()
	for i := 0; i < nbOps; i++ {
		iConcrete.Sum(Int(10))
	}
	_ = iConcrete
	fmt.Printf("[concrete]  computed %d sums in %v\n", nbOps, time.Now().Sub(start))

	var iInterface Summable = &zero
	start = time.Now()
	for i := 0; i < nbOps; i++ {
		iInterface.Sum(Int(10))
	}
	_ = iInterface
	fmt.Printf("[interface] computed %d sums in %v\n", nbOps, time.Now().Sub(start))
}

The results look like these:

$ go version
go version go1.6.2 darwin/amd64
$ sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
$ go run concrete_vs_interface_pointers_inplace.go
[concrete]  computed 100000000 sums in 215.192313ms
[interface] computed 100000000 sums in 222.486475ms

The overhead of going through an interface is now barely noticeable.. in fact, it's sometimes even faster than the concrete calls!

Wait... did the concrete calls just get slower?!

Yes, they did.
Removing the return value of the Sum method noticeably made the concrete calls ~17% slower (going from 180ms on average to 210ms).

I haven't had the time to look into this, so I'm not sure about the exact cause for this slow-down; but I'm going to assume that the presence of the return value allows the compiler to do some tricky optimizations...
I'll dig into this once I find the time; if you know what's going on, please open an issue!

Interface calls are now as fast as concrete calls!

Finally, now that we've completely removed the need to build interfaces when assigning Sum's return values; we've removed all the overhead we could remove.

In this configuration, using either concrete or interface calls has virtually the same cost (although, in reality, concrete calls can be made faster with the use of a return value).

Conclusion

Technically, Go interfaces' method-dispatch machinery barely has any overhead compared to a simple method call on a concrete type.

In practice, due to the way interfaces are implemented, it's easy to stumble upon various more-or-less obvious pitfalls that can result in a lot of overhead, primarily caused by implicit allocations and copies.
Sometimes, compiler optimizations will save you; and sometimes they won't.

About

[Go] interface-bench - a quick look at some of Go's subtleties regarding the use of interfaces.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages