字素生成 - 时间与内存复杂度答案

【问题标题】：Grapheme generation - time vs. memory complexity字素生成 - 时间与内存复杂度
【发布时间】：2011-07-14 20:56:20
【问题描述】：

我正在编写一个程序来从文本文件中生成“多图”数据，这些数据基本上是字素与其在文本文件中出现频率之间的映射，例如：

aaaa : 0
aaab : 0
aaac : 0
...
thel : 10
them : 250
...
zzzz : 0

基本思想是，然后您可以根据多图数据对字符串“评分”，以测试它与文本文件语言的相似程度。评分功能必须非常快。因此，我希望通过使用 n 维数组来实现对数据的直接访问。例如：

data[n('t')][n('h')][n('e')][n('m')]

其中 n(char) 是一个对字符进行规范化的函数，例如 a -> 0、b -> 1、c -> 2 等。无论如何，问题在于：26^n 变大了，非常快！如果我每个元素使用 4 个字节，则不同的 n 值需要以下内存：

104 乙
3 KB
69 KB
2 MB
45 MB
1 GB
30 GB
778 GB

所以看起来当n > 3时，栈内存不足，而当n > 6时，大多数堆内存不足。理想情况下，我希望能够生成任何合理长度的多图文件——最多 10 个左右。有什么想法可以实现吗？

我考虑过为数组的每个元素使用少于一个字节的可能性。我真的只需要索引“a-z”，也许还有一些特殊字符（空格、标点符号），所以可能只需要 5 位（0-31）就可以了。这可能吗？如果可以的话，我可能会节省 38% 的内存。您认为这会如何影响时间复杂度？

一种选择是使用散列函数而不是数组。这意味着我只在实际存在的键上使用内存，而不是频率总是为 0 的“qxzf”。内存需求将大大减少，但我担心时间复杂度会受到严重影响。你怎么看？

也许我可以使用某种树数据结构？字形本身适合这种表示，但同样，时间复杂性肯定会受到打击。我认为访问数据需要“n”个步骤，而不是 1 个。

最后，我正在考虑对评分函数进行多线程处理。我宁愿不为每个线程分配数据的副本。您认为可以结合使用一两个与 Peterson 的算法来锁定元素吗？

提前致谢。

【问题讨论】：

您是否对简单地使用 Dictionary 进行过任何基准测试？它可能会更慢，但对于较大的 n，节省空间会比提前为每个可能的字符串预分配空间更好
我明天试试基准测试。我想它会慢几倍。它必须在每次评分时进行字符串比较。
我和布兰登在一起。首先简单地制作原型以获得真实世界的起点并根据需要添加复杂性。顺便说一句，我猜散列仍然足够接近恒定时间查找以使其可行（并且可能对缓存更友好。）
@Christopher：关于多线程，有多少评分函数位于临界区？待测字符串是否有自己的字素频率结构？您想对单个字符串进行多线程评分，还是每个线程都应该为不同的字符串评分？评分函数是否需要对共享字素频率结构的写入权限？
评分函数将是多线程的，每个线程采用不同的字符串进行评分。一旦生成多图数据，它就保持不变。评分函数的 CR 将仅从数据结构中读取。

标签： c++ c algorithm bitmap complexity-theory

【解决方案1】：

Tries 提供了良好的时空权衡。一个普通的trie，其中每个节点（例如前缀“iq”）都有一个由字符串中的下一个字符（例如'x'）索引的子指针数组，仍然会以空值的形式浪费空间子指针数组，但您将节省空间，因为没有以该前缀为根的分支（例如“iqx”）。其他尝试通过仅存储指向存在的子级的指针来减少空间量但增加时间复杂度（尽管不一定很多），这需要搜索子级指针，通常在子级数量的对数时间内。后一种类型的一些尝试将给定前缀的所有指针存储在单个节点中；其他人（例如ternary search tries）使用多个节点。

使用尝试的查找大致为 O(n)，但由于 n 相当小，因此实际性能可能足够快以满足您的目的。根据您计算事物的方式，多维数组访问本身就是 O(n)，因为查找 n 个字符的键涉及评估具有 n 项的多项式（@ 987654326@).

如果空间要求仍然太高，即使对于虚拟内存，您也需要将大部分结构存储在磁盘上，例如B+ treesallow。在这种情况下，B+ 树将提供哈希表的底层实现。这当然会造成相当大的性能损失，但一旦内存需求达到一定水平，这是不可避免的。

我考虑过使用少于一个字节来索引数组的每个维度的可能性。

完全可以通过这种方式减少潜在数组索引的数量。除了使用专门的数据结构之外，您还可以这样做。例如，这将减少 trie 中节点的扇出，减少空指针的数量。

您需要一个将字符映射到数组键的函数，这只会稍微增加时间复杂度。使用表查找将导致较低的常数时间增加和较小的空间增加（~256 字节）。

您可能还需要以与字符串长度成线性关系的时间复杂度对样本数据和待测试字符串进行预处理，以过滤/映射无效字符（例如将大写字母转换为小写字母） .

最后，我正在考虑对评分函数进行多线程处理。

这里的收益取决于有多少评分函数的计算花费在从字素结构中读取之外。如果在此之外花费的时间很少，那么线程将花费大部分时间等待，并且您不会看到太多的性能改进。 Amdahl's law 适用于此。

根据您的评论，多线程评分功能可能不需要锁定来进行只读访问。只要只读访问不改变结构本身，遍历结构的所有状态都完全包含在读取函数中，读取函数调用的任何函数（例如哈希函数）都是线程安全的，并且整个结构都适合可用内存，那么如果多个线程同时从树中读取，则不应该发生冲突。

如果您使用磁盘支持的方法（例如使用 B+ 树），则最后一个要求将不成立。在这种情况下，您可能需要锁定处理磁盘块的代码以防止抖动。

【讨论】：

我倾向于一种解决方案，其中要使用的数据结构取决于可用的内存量。也许对于较小的 n 值，可以使用 n 维数组，对于中间值，可以使用哈希映射，对于较大的值，可以使用 trie。关于哈希映射或 trie 是否更快的读取存在一些不确定性（在这种情况下，这才是最重要的）。我想这是我应该做的基准测试？

【解决方案2】：

trie 可能与您的方法一样快（n 次数组查找与 n 次树节点遍历）并节省大量空间。散列也可以工作，查找速度可能更快，但需要更多空间。

【讨论】：