《Go map使用Swiss Table重新实现，性能最高提升近50%》的评论

作者：bigwhite

bigwhite — Fri, 13 Jun 2025 21:42:46 +0000

是的，go的实现没有是16个slot，而是用了8个slot。google原生发布swiss table算法时默认应该是16 slot。Abseil C++ library采用的应该是16-slot的实现。

作者：Kobe

Kobe — Fri, 13 Jun 2025 08:25:20 +0000

我们看到：swiss table将所谓的桶（这里叫slot）分为多个group，每个group中有16个slot，这也是swiss table的创新，即将开放寻址方法中的probing(探测key碰撞后下一个可用的位置(slot))放到一个16个slot的group中进行，这样的好处是可以通过一个SIMD指令并行探测16个slot，这种方法也被称为Group Probing。

不是 8 个 slot 吗？
https://go.dev/blog/swisstable

作者：bigwhite

bigwhite — Thu, 12 Dec 2024 13:31:40 +0000

有些时候compiler&runtime组是这样的，之前我也是完全不知道这事儿。

作者：Kukla

Kukla — Thu, 12 Dec 2024 07:06:52 +0000

是啊，之前没有任何讨论，就决定替换掉了原来的实现
不过今天发现，上星期提交者也开了 issue: https://github.com/golang/go/issues/70683
当然，代码已经提交，这个也就关掉了

作者：bigwhite

bigwhite — Tue, 26 Nov 2024 22:35:40 +0000

go 1.24中的确可以使用GOEXPERIMENT=synchashtriemap 开启基于hashtriemap的更快的sync.Map https://go.dev/cl/608335

作者：bigwhite

bigwhite — Wed, 20 Nov 2024 13:36:10 +0000

的确如你所说。不过，这个commit没有任何issue对应，似乎是runtime组自己的一个优化，且目前依然是experiment。看来我对hashtriemap的理解有误。以前sync.Map用的就很少，关注的也不多。

作者：Kukla

Kukla — Wed, 20 Nov 2024 02:34:23 +0000

https://github.com/golang/go/commit/aecb8faa91e2b40e3651ee93c8e70635ed367677 这个提交不是替换原始的 sync.Map 吗

作者：bigwhite

bigwhite — Wed, 20 Nov 2024 01:35:33 +0000

此外trie这种结构也叫prefix tree，hash trie更适合高效的前缀查找，比如下面场景：

- 自动补全：在输入时根据前缀快速查找可能的选项。
- 字典实现：用于高效的单词查找和存储。
- 路由表：在网络中管理路由信息。

但可能不适合作为通用hash map的实现。

作者：bigwhite

bigwhite — Wed, 20 Nov 2024 01:30:11 +0000

这个目前看是给unique包内部用的。虽然提及“can be used elsewhere as well”，但至少目前没看到有proposal说要用其换掉sync.Map的内部实现呢。

作者：Kukla

Kukla — Tue, 19 Nov 2024 08:57:36 +0000

也就是这个 https://github.com/golang/go/blob/master/src/internal/sync/hashtriemap.go