地图与切换性能的关系

地图与切换性能的关系

映射不适用，因为索引索引是在运行时评估的，并且从映射中获取元素所涉及的 *** 作比仅进行一次（切片）索引要多。某些

switch

es（带有

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 pre array, do a specific action        for _, v := range pre { c := sliceCode[v] if c == 0 {     fail++ } else {     success += c }        }    }}

以及基准测试结果：

BenchmarkMap-4          10000000    148 ns/opBenchmarkSlice-4        100000000    17.6 ns/opBenchmarkSwitch-4       50000000     31.0 ns/op

在这个具体示例中，切片解决 方案的速度 比

switch

解决方案快两倍！

笔记：

上面我提到过，如果您有一个类似的索引

1000

，则至少需要

1001

元素。这部分是正确的。例如，如果您有类似的索引

990..1000

，则可以有一个简单的索引转换逻辑，例如

index- 990

，那么仅包含11个元素的切片就足够了。

另请注意，在使用逗号分隔的习惯用法为地图编制索引时，我们能够判断元素是否在地图中。对于切片，我们没有该选项。因此，我们必须从有效的元素类型集中指定一个值，并将其用作“丢失”信号。在上面的示例中，

0

对我们来说是完美的，因为它没有被使用（并且所有未明确列出的元素都

0

默认设置为）。如果在您的示例中

int32

可以使用所有有效值，则另一个选择是使用包装器或指针类型作为可能具有

nil

值的切片的元素类型，指示缺少索引的元素。