地图与切换性能的关系

Question

考虑这个基准，我们在这里比较地图访问与切换

var code = []int32{0, 10, 100, 100, 0, 10, 0, 10, 100, 14, 1000, 100, 1000, 0, 0, 10, 100, 1000, 10, 0, 1000, 12}
var mapCode = map[int32]int32{
    0:    1,
    10:   2,
    100:  3,
    1000: 4,
}

func BenchmarkMap(b *testing.B) {
    success := int32(0)
    fail := int32(0)
    for n := 0; n < b.N; n++ {
        // for each value in code array, do a specific action
        for _, v := range code {
            c, ok := mapCode[v]
            if !ok {
                fail++
            } else {
                success += c
            }
        }
    }
}

func BenchmarkSwitch(b *testing.B) {
    success := int32(0)
    fail := int32(0)
    for n := 0; n < b.N; n++ {
        // for each value in code array, do a specific action
        for _, v := range code {
            switch v {
            case 0:
                success++
            case 10:
                success += 2
            case 100:
                success += 3
            case 1000:
                success += 4
            default:
                fail++
            }
        }
    }
}

结果如下：

BenchmarkMap-2           5000000           277 ns/op           0 B/op          0 allocs/op
BenchmarkSwitch-2       30000000            48.2 ns/op         0 B/op          0 allocs/op

因此，使用地图似乎比切换要慢。

我目前正在尝试使用类似于的代码来优化功能BenchmarkMap()，其中地图访问是瓶颈，但是由于程序启动时会动态生成地图，因此我无法使用switch（即，它可能会根据输入参数而变化）

有没有办法获得switch x {}与动态生成的地图类似的性能？

Answer 1

映射不适用，因为索引索引是在运行时评估的，并且从映射中获取元素所涉及的操作比仅进行一次（切片）索引要多。某些switches（带有case具有恒定表达式的分支）甚至可以在编译时进行优化。

但是地图并不是唯一的“动态”结构。另外一个，有切片。切片可以索引，就像地图一样。

是的，切片是基础数组 连续段 的描述符。这意味着，如果您的索引如1000，则切片至少需要包含1000+1 = 1001元素。

因此，如果您愿意为了性能而牺牲一些内存并使用切片而不是映射， 则甚至可以比使用以下switch语句的解决方案更快：

var sliceCode = []int32{
    0:    1,
    10:   2,
    100:  3,
    1000: 4,
}

func BenchmarkSlice(b *testing.B) {
    success := int32(0)
    fail := int32(0)
    for n := 0; n < b.N; n++ {
        // for each value in code array, do a specific action
        for _, v := range code {
            c := sliceCode[v]
            if c == 0 {
                fail++
            } else {
                success += c
            }
        }
    }
}

以及基准测试结果：

BenchmarkMap-4          10000000               148 ns/op
BenchmarkSlice-4        100000000               17.6 ns/op
BenchmarkSwitch-4       50000000                31.0 ns/op

在这个具体示例中，切片解决 方案的速度 比switch解决方案快两倍！

笔记：

上面我提到过，如果您有一个类似的索引1000，则至少需要1001元素。这部分是正确的。例如，如果您有类似的索引990..1000，则可以有一个简单的索引转换逻辑，例如index - 990，那么仅包含11个元素的切片就足够了。

另请注意，在使用逗号分隔的习惯用法为地图编制索引时，我们能够判断元素是否在地图中。对于切片，我们没有该选项。因此，我们必须从有效的元素类型集中指定一个值，并将其用作“丢失”信号。在上面的示例中，0对我们来说是完美的，因为它没有被使用（并且所有未明确列出的元素都0默认设置为）。如果在您的示例中int32可以使用所有有效值，则另一个选择是使用包装器或指针类型作为可能具有nil值的切片的元素类型，指示缺少索引的元素。