Does a type assertion / type switch have bad performance / is slow in Go?
Solution 1
It is very easy to write a Benchmark test to check it: http://play.golang.org/p/E9H_4K2J9-
package main
import (
"testing"
)
type myint int64
type Inccer interface {
inc()
}
func (i *myint) inc() {
*i = *i + 1
}
func BenchmarkIntmethod(b *testing.B) {
i := new(myint)
incnIntmethod(i, b.N)
}
func BenchmarkInterface(b *testing.B) {
i := new(myint)
incnInterface(i, b.N)
}
func BenchmarkTypeSwitch(b *testing.B) {
i := new(myint)
incnSwitch(i, b.N)
}
func BenchmarkTypeAssertion(b *testing.B) {
i := new(myint)
incnAssertion(i, b.N)
}
func incnIntmethod(i *myint, n int) {
for k := 0; k < n; k++ {
i.inc()
}
}
func incnInterface(any Inccer, n int) {
for k := 0; k < n; k++ {
any.inc()
}
}
func incnSwitch(any Inccer, n int) {
for k := 0; k < n; k++ {
switch v := any.(type) {
case *myint:
v.inc()
}
}
}
func incnAssertion(any Inccer, n int) {
for k := 0; k < n; k++ {
if newint, ok := any.(*myint); ok {
newint.inc()
}
}
}
EDIT Oct. 09, 2019
It appears that the methods demonstrated above are equal and have no advantage over one another. Here are the results from my machine (AMD R7 2700X, Golang v1.12.9):
BenchmarkIntmethod-16 2000000000 1.67 ns/op
BenchmarkInterface-16 1000000000 2.03 ns/op
BenchmarkTypeSwitch-16 2000000000 1.70 ns/op
BenchmarkTypeAssertion-16 2000000000 1.67 ns/op
PASS
AND AGAIN:
BenchmarkIntmethod-16 2000000000 1.68 ns/op
BenchmarkInterface-16 1000000000 2.01 ns/op
BenchmarkTypeSwitch-16 2000000000 1.66 ns/op
BenchmarkTypeAssertion-16 2000000000 1.67 ns/op
PREVIOUS RESULTS on Jan. 19, 2015
On my amd64 machine, I'm getting the following timing:
$ go test -bench=.
BenchmarkIntmethod 1000000000 2.71 ns/op
BenchmarkInterface 1000000000 2.98 ns/op
BenchmarkTypeSwitch 100000000 16.7 ns/op
BenchmarkTypeAssertion 100000000 13.8 ns/op
So it looks like accessing the method via type switch or type assertion is about 5-6 times slower than calling the method directly or via interface.
I don't know if C++ is slower or if this slowdown is tolerable for your application.
Solution 2
I wanted to verify siritinga's answer by myself, and check whether removing the check in TypeAssertion would make it faster. I added the following in their benchmark:
func incnAssertionNoCheck(any Inccer, n int) {
for k := 0; k < n; k++ {
any.(*myint).inc()
}
}
func BenchmarkTypeAssertionNoCheck(b *testing.B) {
i := new(myint)
incnAssertionNoCheck(i, b.N)
}
and re-ran the benchmarks on my machine.
BenchmarkIntmethod-12 2000000000 1.77 ns/op
BenchmarkInterface-12 1000000000 2.30 ns/op
BenchmarkTypeSwitch-12 500000000 3.76 ns/op
BenchmarkTypeAssertion-12 2000000000 1.73 ns/op
BenchmarkTypeAssertionNoCheck-12 2000000000 1.72 ns/op
So it seems that the cost of doing a type switch went down significantly from Go 1.4 (that I assume siritinga used) to Go 1.6 (that I'm using): from 5-6 times slower to less than 2 times slower for a type switch, and no slow-down for a type assertion (with or without check).
Solution 3
My Results using Go 1.9
BenchmarkIntmethod-4 1000000000 2.42 ns/op
BenchmarkInterface-4 1000000000 2.84 ns/op
BenchmarkTypeSwitch-4 1000000000 2.29 ns/op
BenchmarkTypeAssertion-4 1000000000 2.14 ns/op
BenchmarkTypeAssertionNoCheck-4 1000000000 2.34 ns/op
Type Assertion is much faster now, but the most interesting removing the type check makes it slow.
Solution 4
TL;DR: it really depends on type distribution, but interfaces are the safest choice unless you are sure that types will appear in regular chunks. Also consider that if your code is executed infrequently, the branch predictor will also not be warmed up.
Long explanation:
On go1.9.2 on darwin/amd64
BenchmarkIntmethod-4 2000000000 1.67 ns/op
BenchmarkInterface-4 2000000000 1.89 ns/op
BenchmarkTypeSwitch-4 2000000000 1.26 ns/op
BenchmarkTypeAssertion-4 2000000000 1.41 ns/op
BenchmarkTypeAssertionNoCheck-4 2000000000 1.61 ns/op
An important thing to note here is that a type switch with only one branch is not a very fair comparison against using an interface. The CPU branch predictor is going to get very hot, very fast and give very good results. A better bench mark would use pseudo random types and an interface with pseudo random receivers. Obviously, we need to remove the static method dispatch and stick to just interfaces versus typeswitch (type assertion also becomes less meaningful since it would require a lot of if statements, and no one would write that instead of using a type switch). Here is the code:
package main
import (
"testing"
)
type myint0 int64
type myint1 int64
type myint2 int64
type myint3 int64
type myint4 int64
type myint5 int64
type myint6 int64
type myint7 int64
type myint8 int64
type myint9 int64
type DoStuff interface {
doStuff()
}
func (i myint0) doStuff() {
i += 0
}
func (i myint1) doStuff() {
i += 1
}
func (i myint2) doStuff() {
i += 2
}
func (i myint3) doStuff() {
i += 3
}
func (i myint4) doStuff() {
i += 4
}
func (i myint5) doStuff() {
i += 5
}
func (i myint6) doStuff() {
i += 6
}
func (i myint7) doStuff() {
i += 7
}
func (i myint8) doStuff() {
i += 8
}
func (i myint9) doStuff() {
i += 9
}
// Randomly generated
var input []DoStuff = []DoStuff{myint0(0), myint1(0), myint1(0), myint5(0), myint6(0), myint7(0), myint6(0), myint9(0), myint7(0), myint7(0), myint6(0), myint2(0), myint9(0), myint0(0), myint2(0), myint3(0), myint5(0), myint1(0), myint4(0), myint0(0), myi
nt4(0), myint3(0), myint9(0), myint3(0), myint9(0), myint5(0), myint0(0), myint0(0), myint8(0), myint1(0)}
func BenchmarkInterface(b *testing.B) {
doStuffInterface(b.N)
}
func BenchmarkTypeSwitch(b *testing.B) {
doStuffSwitch(b.N)
}
func doStuffInterface(n int) {
for k := 0; k < n; k++ {
for _, in := range input {
in.doStuff()
}
}
}
func doStuffSwitch(n int) {
for k := 0; k < n; k++ {
for _, in := range input {
switch v := in.(type) {
case *myint0:
v.doStuff()
case *myint1:
v.doStuff()
case *myint2:
v.doStuff()
case *myint3:
v.doStuff()
case *myint4:
v.doStuff()
case *myint5:
v.doStuff()
case *myint6:
v.doStuff()
case *myint7:
v.doStuff()
case *myint8:
v.doStuff()
case *myint9:
v.doStuff()
}
}
}
}
And the results:
go test -bench .
goos: darwin
goarch: amd64
pkg: test
BenchmarkInterface-4 20000000 74.0 ns/op
BenchmarkTypeSwitch-4 20000000 119 ns/op
PASS
ok test 4.067s
The more types and the more random the distribution, the bigger win interfaces will be.
To show this disparity I changed the code to benchmark random choice versus always picking the same type. In this case, the typeswitch is again faster, while the interface is the same speed, here is the code:
package main
import (
"testing"
)
type myint0 int64
type myint1 int64
type myint2 int64
type myint3 int64
type myint4 int64
type myint5 int64
type myint6 int64
type myint7 int64
type myint8 int64
type myint9 int64
type DoStuff interface {
doStuff()
}
func (i myint0) doStuff() {
i += 0
}
func (i myint1) doStuff() {
i += 1
}
func (i myint2) doStuff() {
i += 2
}
func (i myint3) doStuff() {
i += 3
}
func (i myint4) doStuff() {
i += 4
}
func (i myint5) doStuff() {
i += 5
}
func (i myint6) doStuff() {
i += 6
}
func (i myint7) doStuff() {
i += 7
}
func (i myint8) doStuff() {
i += 8
}
func (i myint9) doStuff() {
i += 9
}
// Randomly generated
var randInput []DoStuff = []DoStuff{myint0(0), myint1(0), myint1(0), myint5(0), myint6(0), myint7(0), myint6(0), myint9(0), myint7(0), myint7(0), myint6(0), myint2(0), myint9(0), myint0(0), myint2(0), myint3(0), myint5(0), myint1(0), myint4(0), myint0(0),
myint4(0), myint3(0), myint9(0), myint3(0), myint9(0), myint5(0), myint0(0), myint0(0), myint8(0), myint1(0)}
var oneInput []DoStuff = []DoStuff{myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0),
myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0), myint1(0)}
func BenchmarkRandomInterface(b *testing.B) {
doStuffInterface(randInput, b.N)
}
func BenchmarkRandomTypeSwitch(b *testing.B) {
doStuffSwitch(randInput, b.N)
}
func BenchmarkOneInterface(b *testing.B) {
doStuffInterface(oneInput, b.N)
}
func BenchmarkOneTypeSwitch(b *testing.B) {
doStuffSwitch(oneInput, b.N)
}
func doStuffInterface(input []DoStuff, n int) {
for k := 0; k < n; k++ {
for _, in := range input {
in.doStuff()
}
}
}
func doStuffSwitch(input []DoStuff, n int) {
for k := 0; k < n; k++ {
for _, in := range input {
switch v := in.(type) {
case *myint0:
v.doStuff()
case *myint1:
v.doStuff()
case *myint2:
v.doStuff()
case *myint3:
v.doStuff()
case *myint4:
v.doStuff()
case *myint5:
v.doStuff()
case *myint6:
v.doStuff()
case *myint7:
v.doStuff()
case *myint8:
v.doStuff()
case *myint9:
v.doStuff()
}
}
}
}
Here are the results:
BenchmarkRandomInterface-4 20000000 76.9 ns/op
BenchmarkRandomTypeSwitch-4 20000000 115 ns/op
BenchmarkOneInterface-4 20000000 76.6 ns/op
BenchmarkOneTypeSwitch-4 20000000 68.1 ns/op
Solution 5
I run bench example by @siritinga in my laptop (go1.7.3 linux/amd64), got this result:
$ go test -bench .
BenchmarkIntmethod-4 2000000000 1.99 ns/op
BenchmarkInterface-4 1000000000 2.30 ns/op
BenchmarkTypeSwitch-4 2000000000 1.80 ns/op
BenchmarkTypeAssertion-4 2000000000 1.67 ns/op
Ory Band
Backend engineer. Loves Clojure, Golang and Linux. Interested in distributed systems. https://ory.band
Updated on July 08, 2022Comments
-
Ory Band almost 2 years
How slow is using type assertions / type switches in Go, as a method of run-time type discovery?
I've heard that in C/C++ for example, discovering types at run time has bad performance. To bypass that, you usually add type members to classes, so you can compare against these instead of casting.
I haven't found a clear answer for this throughout the www.
Here's an example of what I'm asking about - Is this considered fast when compared to other type checking methodologies (like mentioned above, or others I'm not aware of)?
func question(anything interface{}) { switch v := anything.(type) { case string: fmt.Println(v) case int32, int64: fmt.Println(v) case SomeCustomType: fmt.Println(v) default: fmt.Println("unknown") } } -
JimB over 9 yearsI would remove "casting" from your answer. A type switch is different than a type cast, which go doesn't allow without the use of the
unsafepackage. You also forgot a bare type assertion, which is slightly faster than a type switch. -
siritinga over 9 yearsI haven't included the type assertion, you are right, but if you chain several if else to do what a switch do, do you think it would be faster? Regarding type casting, I'm not sure what you mean. Isn'tmynewint := any.(*myint)type casting? -
JimB over 9 yearsif+else's might be about the same as a switch, but a single type assertion is very common in Go code. That isn't a cast (in the C or Java sense). It's a type assertion, and is type-safe. A cast is more akin to
(*[8]byte)(unsafe.Pointer(&myInt)) -
siritinga over 9 yearsThanks JimB, I thought that type assertion was the optional second
okparameter and the first was the cast. -
JimB over 9 yearsThe comma-ok form gives you the bool to check; the non-ok form is when you want it to panic if the assertion is invalid. The underlying assertion is the same.
-
siritinga over 9 yearsI have included the type assertion, that as you said, it is a minor improvement with respect to type switch, and removed "casting". Thanks!
-
Ory Band almost 8 yearsInteresting. I wonder what happened. Maybe someone can provide some docs explaining this performance increase?
-
Antimony almost 8 years@JimB A type assertion is a cast in the Java sense, for non primative types. Casting references in Java is a "type assertion"
-
Kr0e almost 8 yearsJust tested this with go1.7 on a beefy MacBook Pro, results: BenchmarkIntmethod-8 2000000000 1.97 ns/op BenchmarkInterface-8 1000000000 2.27 ns/op BenchmarkTypeSwitch-8 2000000000 1.90 ns/op BenchmarkTypeAssertion-8 2000000000 1.89 ns/op PASS ----------- Seems like, there is almost no overhead anymore :-)
-
physphun over 7 yearswith the SSA added in Go 1.7, I would be shocked if this code does not get optimized out to bypass the type casting since there is only one case. I would guess that this is the reason for the similar performance seen by @kr0e
-
physphun over 7 years@Ted are you sure you are using Go 1.6? the SSA added in 1.7 could be responsible for optimizing this.
-
Ted over 7 years@physphun Go 1.7 wasn't released when I posted this answer, so yes :-) -
physphun over 7 yearsAh! just checking. This performance gain really feels too good to be true.
-
prl900 over 7 years@physphun: The number of cases in the type switch statement does not affect performance of this benchmark. This playground example contains two types implementing the Inccer interface play.golang.org/p/s4SEk6Ell6 and performance is the same as when using only one type in the type switch. The new compiler must be doing smart things independently of the number of cases in the type assertion switch. -
zer09 almost 7 yearscan you post your benchmark score? Testing your suggestion on Go 1.9 make it worst. Thanks
-
Seer over 6 yearsPeople had commented / posted answers a couple of years ago about this...
-
zer09 over 6 years@Seer what is your implying about your comment? sorry I didn't get it.
-
Patrick over 6 yearsIt turns out go actually compiles (at least in 1.9.2) a type switch into a series of else ifs instead of a jump table. If you make the one type into all test9s instead of all test1s, the following results: BenchmarkRandomInterface-4 20000000 77.2 ns/op BenchmarkRandomTypeSwitch-4 20000000 114 ns/op BenchmarkOneInterface-4 20000000 76.6 ns/op BenchmarkOneTypeSwitch-4 10000000 133 ns/op So this suggests even more firmly to stick with interfaces if you have more than a few possible types.
-
luistm over 6 yearsWhich was the Go version used for this test?
-
leaf bebop over 6 yearsThe performance issue is due to Go's inline complition. Go can't inline an interface function call, and couldn't inline for type switch (but can now, as Go1.9 can do this). adds a comment
//go:noinline(not sure if Go1.6 supports it or not) before the declaration ofincand test again, the result would be all almost the same. -
Larytet over 4 years@physphun you are right. This bench play.golang.org/p/3Nl6ilcsfIu demos inlining and optimization out. On my machine BenchmarkTypeAssert-4 300000 4782 ns/op BenchmarkTypeAssertFast-4 5000000 356 ns/op -
Larytet over 4 yearsSee play.golang.org/p/nDXjsTcxZqX compiler optimizes the code out
-
Oppen over 2 yearsI'd suggest adding
//go:noinlineto the different implementations. This is because inlining ends up devirtualizing a great deal. Just to give an example, with the code verbatim I get a ratio of 0.92 of ns/op for interface vs plain int, while with the noinline directive that becomes 1.11. For non-trivial methods and less predictable types inlining and devirtualization is more unlikely to happen, and mostly we're not comparing what we think.
