字素生成时间vs.内存复杂度

Grapheme generation - time vs. memory complexity

本文关键字：vs 内存 复杂度 时间      更新时间：2023-10-16

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

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值使用以下内存:

  1. 104 B
    2. <
  2. 3 KB/gh>
  3. 69 KB
  4. 2 MB
    5. <
  5. 45 MB/gh>
  6. 1 GB
    7. <
  7. 30 GB/gh>
  8. 778 GB

似乎当n> 3时，堆栈耗尽内存，当n> 6时，大多数堆耗尽内存。理想情况下，我希望能够生成任何合理长度的多图文件-最多10个左右。你知道我该怎么做吗?

我考虑过为数组的每个元素使用少于一个字节的可能性。我只需要索引'a-z'和一些特殊字符(空格，标点符号)，所以可能需要5位(0 - 31)。这可能吗?如果可以的话，我可能会节省38%的内存。你认为这会如何影响时间复杂度?

一种选择是使用散列函数而不是数组。这意味着我只在实际存在的键上使用内存，而不是'qxzf'，因为它的频率总是为0。内存需求会大大降低，但我担心时间复杂度会受到严重影响。你觉得呢?

也许我可以使用某种树形数据结构?字素适合这种表示方式，但是时间复杂度肯定会受到影响。我认为访问数据需要"n"步，而不是1步。

最后，我正在考虑多线程的评分功能。我宁愿不为每个线程分配数据的副本。你认为有可能在Peterson的算法中结合使用bit或two来锁定元素吗?

尝试提供了很好的时间-空间权衡。一个普通的树，其中每个节点(例如前缀"iq")都有一个由字符串中的下一个字符索引的子指针数组(例如:'x')，仍然会在子指针数组中以空的形式浪费空间，但您将节省空间，因为该前缀中没有分支(例如:"iqx")。其他尝试通过仅存储指向存在的子指针来减少空间量，但增加了时间复杂度(尽管不一定太多)，这需要搜索子指针，通常在对数时间内搜索子指针的数量。后一种类型的一些尝试将给定前缀的所有指针存储在单个节点中;其他的(比如三元搜索)使用多个节点。

使用tries查找

大约是O(n)，但是由于n相当小，因此实际性能对于您的目的来说已经足够快了。根据你计数的方式，多维数组访问本身是O(n)，因为查找一个n个字符的键涉及计算一个具有n项的多项式(data[a1]...[an] == data + sum(i=1..n, ai * 256i-1))。

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

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

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

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

您可能还需要预处理样本数据和待测试的字符串，以过滤掉/映射无效字符(例如将大写转换为小写)，时间复杂度与字符串长度呈线性关系。

最后，我正在考虑多线程的评分函数。

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

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

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

一个树可能和你的方法一样快(n个数组查找vs n个树节点遍历)并且节省大量空间。散列也可以工作，并且可能更快地查找，但需要更多的空间。

相关文章：