大家好，我是煎鱼。
本次 Go1.24 新版本又带来了一个比较不错的优化点，Go map 做了一个比较大的改变，有了一定的性能优化。
咱们又可以躺着升级个版本就得到一定的性能益处了。今天这篇文章将主要针对这部分进行新版本特性分享。
该提案（go/issues/54766[1]）的发起方是来自字节的大佬们。主要目的建议在 Go map 使用 Swiss Table 来替换 Hashmap 的原始实现。
图片
这里不得不提到 Swiss Table 是什么？好像比 Hashmap 牛逼许多。
Swiss Table 是什么
Swiss Table[2] 是一种用于解决哈希冲突的高效哈希表实现，最初由 Google 的工程师开发，在 2017 年首次在技术大会中提出。并应用于其开源的 Abseil C++ 库中。
图片
Swiss Table 的名字来源于其独特的查找方式，该方式结合了紧凑的存储和高效的查找性能，类似瑞士军刀般功能强大且多用途。
以下简单介绍 Swiss Table 的几个核心概念。有想了解的同学可以浅尝。不感兴趣的可以跳过该章节。
紧凑的存储布局
- Swiss Table 使用小块连续内存（称为 bucket groups）存储哈希表中的条目。每个 bucket group 通常包含 16 个条目。
- 表的元数据（如哈希值的高位部分）存储在一个紧凑的位图结构中，这使得查找操作可以快速跳过空的或不匹配的条目。
高效的查找
- 查找时，Swiss Table 通过元数据位图快速定位可能的条目位置，避免遍历所有条目。
- 使用 SIMD（单指令多数据）技术，在现代 CPU 上一次性检查多个桶，大大提高了查找性能。
缓存友好
- 连续存储布局和紧凑的元数据结构减少了缓存未命中率，提高了性能。
- 查找和插入操作充分利用了 CPU 的缓存层次结构。
减少内存碎片
- Swiss Table 在设计上尽量减少内存使用，同时保持高性能。
- 它通过有效的内存管理策略减少了因冲突或增长导致的内存碎片。
渐进式增长
- 在需要扩展哈希表时，Swiss Table 采用渐进式增长策略，避免了传统哈希表一次性扩展带来的性能波动。
对 Go map 的用处和效益
在字节大佬们提供的测试报告中，Go map 使用 Swiss Table 而不是 Hashmap 时，能够带来以下的性能效益：
- 查询：在查询较大的 hashmap 或查询 hashmap 中不存在的元素时，有显著的提升（20%~50%）。在查询元素较少的 hashmap 时，性能下降最多 20%。
- 插入和删除：在几乎所有情况下都有显著提升（20%~50%）。
- 迭代（iterate）：性能提升了大约 10%。
- 内存情况：在大多数情况下，内存使用量减少了 0%~25%。重复使用固定大小的 hashmap 不再消耗任何额外的内存。
使用 Swiss Table 的改造是对于 Go map 有较大的综合性能提升的。针对这一变更评估了 2 年多（2022 年发起）后，将在 2025 年 2 月发布的 Go1.24 正式被应用。
但由于该特性还处于实验性，希望关闭的同学也可以设置 GOEXPERIMENT=noswissmap 来进行关闭。用于做简单的对照数据实验也是不错的。
总结
本次国内的字节大佬们为 Go 运行时贡献了 Go map 的 Swiss Table 的改造，给 map 带来了较大的性能提高。
参考资料
[1]go/issues/54766: https://github.com/golang/go/issues/54766
[2]Swiss Table: https://abseil.io/about/design/swisstables
