Scala 的 Vector 是如何工作的？

Question

我阅读了 this page 关于 Scala 集合的时间复杂度的文章。正如它所说，Vector 对于所有操作的复杂性是eC。

这让我想知道Vector 是什么。我读了document，上面写着：

由于向量在快速随机选择和快速随机函数更新之间取得了很好的平衡，因此它们目前是 不可变索引序列的默认实现。它由 分支因子为 32 的小端位图矢量树。 局部性非常好，但不连续，这对非常有好处 大序列。

与 Scala 的其他所有内容一样，它非常模糊。 Vector 究竟是如何工作的？

Answer 1

这里的关键字是Trie。 Vector 被实现为Trie 数据结构。 见http://en.wikipedia.org/wiki/Trie。

更准确地说，它是一个“位映射向量树”。我刚刚在这里找到了对结构的足够简洁的描述（以及一个实现 - 显然是在 Rust 中）：

https://bitbucket.org/astrieanna/bitmapped-vector-trie

最相关的摘录是：

Bitmapped Vector Trie 基本上是一棵 32 棵树。级别 1 是一个大小为 32 的数组，无论数据类型如何。 Level 2 是一个由 32 个 Level 1 组成的数组。以此类推，直到：Level 7 是一个由 2 个 Level 6 组成的数组。

更新：回复赖玉轩关于复杂性的评论：

我将不得不假设您在这里的意思是“深度”:-D。 “eC”的图例说“该操作实际上需要恒定的时间，但这可能取决于一些假设，例如向量的最大长度或散列键的分布。”。

如果您愿意考虑最坏的情况，并且考虑到向量的最大大小有一个上限，那么确实可以说复杂度是恒定的。 假设我们认为最大大小为 2^32，那么这意味着最坏的情况是最多 7 次操作，无论如何。 话又说回来，我们总是可以考虑任何类型的集合的最坏情况，找到一个上限并说这是恒定的复杂度，但对于一个示例列表，这意味着一个 40 亿的常数，这不太实际。

但 Vector 正好相反，7 次操作已经超出了实用性，这就是我们可以考虑到其复杂性常数的方式在实践中。

另一种看待这个问题的方式：我们不是在谈论 log(2,N)，而是 log(32,N)。如果您尝试绘制它，您会发现它实际上是一条水平线。所以务实地说，随着集合的增长，您将永远无法看到处理时间的大幅增加。 是的，这仍然不是真正恒定的（这就是为什么它被标记为“eC”而不仅仅是“C”），并且您将能够看到短向量周围的差异（但同样，差异非常小，因为数字的业务增长非常缓慢）。

Answer 2

“Trie”的其他答案很好。但作为一个近似值，只是为了快速理解：

• Vector 内部使用树结构 - 不是二叉树，而是 32 叉树
• 每个“32 路节点”使用 Array[32] 并且可以存储 要么 0-32 对子节点的引用或 0-32 条数据
• 树的结构以某种方式平衡 - 它有“n”级深，但级别 1 到 n-1 是“仅索引级别”（100% 子引用；无数据）并且级别 n 包含所有数据（100% 数据；无子引用）。因此，如果数据元素的数量为“d”，则 n = log-base-32(d) 向上舍入

为什么会这样？很简单：为了性能。

不是为每个单独的数据元素分配数千/数百万/数十亿的内存，而是以 32 个元素块分配内存。结构非常浅，而不是步行数英里深才能找到您的数据 - 它是一棵非常宽且短的树。例如。 5 层深度可以包含 32^5 个数据元素（对于 4 字节元素 = 132GB，即相当大），并且每个数据访问将从根开始查找并遍历 5 个节点（而大数组将使用单个数据访问）。向量不会主动为所有级别 n（数据）分配内存，它会根据需要分配 32 个元素块。它提供类似于大型数组的读取性能，同时具有类似于二叉树的功能特性（功率、灵活性和内存效率）。

:)

Answer 3

这些可能对你来说很有趣：

• Ideal Hash Trees 菲尔·巴格威尔。
• Implementing Persistent Vectors in Scala - Daniel Spiewak
• More Persistent Vectors: Performance Analysis - Daniel Spiewak
• Persistent data structures in Scala