Does a type assertion / type switch have bad performance / is slow in Go?
Asked Answered
D

6

67

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")
    }
}
Duplessismornay answered 19/1, 2015 at 12:39 Comment(4)
Do you have a particular performance you'd like to achieve? Did you benchmark different solutions?Ovipositor
Go keeps an internal type info attached to each interface that's how you can do type conversion. so basically keeping the type as an internal value in your class does the same but probably less efficient.Stob
@Ovipositor nothing in particular. I just want to know if type assertion performance is as bad as casting in C/C++ or other similar languages.Duplessismornay
example: asserting to io.StringWriter is much faster than converting string to []byte(in my case cast-assert was around 12ns-15ns, converting 1024 bytes string to []byte was arond 250ns-300 ns)Greenback
N
50

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.

Noctiluca answered 19/1, 2015 at 15:21 Comment(14)
I 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 unsafe package. You also forgot a bare type assertion, which is slightly faster than a type switch.Stutter
I 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't mynewint := any.(*myint) type casting?Noctiluca
if+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))Stutter
Thanks JimB, I thought that type assertion was the optional second ok parameter and the first was the cast.Noctiluca
The 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.Stutter
I have included the type assertion, that as you said, it is a minor improvement with respect to type switch, and removed "casting". Thanks!Noctiluca
@Stutter A type assertion is a cast in the Java sense, for non primative types. Casting references in Java is a "type assertion"Abran
Just 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 :-)Kazbek
with 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 @kr0eRenunciation
@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.Glimp
Which was the Go version used for this test?Aerodontia
@Renunciation 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/opEgghead
I'd suggest adding //go:noinline to 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.Scandinavian
Two more examples of benchmarks go.dev/play/p/--hp-OGyHwY and go.dev/play/p/ZdJBcye1YM9 Switch is x20 slowerEgghead
S
17

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).

Strenuous answered 7/7, 2016 at 12:18 Comment(6)
Interesting. I wonder what happened. Maybe someone can provide some docs explaining this performance increase?Duplessismornay
@Strenuous are you sure you are using Go 1.6? the SSA added in 1.7 could be responsible for optimizing this.Renunciation
@Renunciation Go 1.7 wasn't released when I posted this answer, so yes :-)Strenuous
Ah! just checking. This performance gain really feels too good to be true.Renunciation
The 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 of inc and test again, the result would be all almost the same.Yenyenisei
See play.golang.org/p/nDXjsTcxZqX compiler optimizes the code outEgghead
L
14

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.

Lilas answered 2/9, 2017 at 14:51 Comment(2)
People had commented / posted answers a couple of years ago about this...Jeroboam
@Jeroboam what is your implying about your comment? sorry I didn't get it.Lilas
B
8

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
Burnett answered 14/12, 2017 at 17:10 Comment(1)
It 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.Burnett
W
4

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
Wide answered 19/1, 2017 at 8:33 Comment(0)
F
1

In your

switch v := anything.(type) {
    case SomeCustomType:
        fmt.Println(v)
...

if you need not SomeCustomType.Fields or methods like in fmt.Println(v), doing

switch anything.(type) { //avoid 'v:= ' interface conversion, only assertion
    case SomeCustomType:
        fmt.Println("anything type is SomeCustomType", anything)
...

should be approximately two times faster

Flail answered 19/1, 2015 at 18:56 Comment(1)
can you post your benchmark score? Testing your suggestion on Go 1.9 make it worst. ThanksLilas

© 2022 - 2024 — McMap. All rights reserved.