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

所以使用map似乎比switch更慢。

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

有没有办法通过动态生成的地图获得与switch x {}类似的效果？

Answer 1

不使用地图，因为indexing地图是在运行时评估的，而从地图获取元素涉及的操作多于单个（切片）索引。某些switch es（case个分支具有常量表达式）即使在编译时也可以进行优化。

但地图不是唯一的＆＃34;动态＆＃34;结构体。对于另一个，有slices。切片可以编入索引，就像地图一样。

是的，切片是底层数组的连续段的描述符。这意味着如果您有像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个元素的切片就足够了。

另请注意，在使用逗号成语索引地图时，我们可以判断元素是否在地图中。有了切片，我们没有这个选择。所以我们必须从元素类型的有效集合中指定一个值，并将其用作＆＃34;缺少＆＃34;信号。在上面的示例中，0对我们来说是完美的，因为没有使用（默认情况下，未明确列出的所有元素都设置为0）。如果在您的示例中可以使用所有有效int32值，则另一个选项是使用包装器或指针类型作为可能具有nil值的切片的元素类型，指示该元素为索引丢失了。

Answer 2

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

没有。对不起。

go中的map vs switch性能

2 个答案: