字形生成 - 时间与内存复杂度

时间:2011-07-14 20:56:20

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

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

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 - >无论如何,这里存在问题:26 ^ n变大,很快!如果我每个元素使用4个字节,则不同的n:

值需要以下内存
  1. 104 B
  2. 3 KB
  3. 69 KB
  4. 2 MB
  5. 45 MB
  6. 1 GB
  7. 30 GB
  8. 778 GB
  9. 所以看来当n>如图3所示,堆栈耗尽内存,并且当n> 6,大多数堆耗尽内存。理想情况下,我希望能够生成任何合理长度的多图文件 - 最多10个左右。我有什么想法可以实现这个目标吗?

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

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

    也许我可以使用某种树数据结构?字形适合于那种表现形式,但同样,时间复杂性肯定会受到打击。我认为访问数据需要'n'步骤,而不是1。

    最后,我正在考虑多线程评分功能。我宁愿不为每个线程分配一份数据副本。你认为可以结合Peterson的算法来锁定一个元素吗?

    提前致谢。

2 个答案:

答案 0 :(得分:2)

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

使用尝试查找大致为O(n),但由于 n 相当小,实际性能可能足够快以达到您的目的。根据您的计算方式,多维数组访问本身就是O(n),因为查找 n 字符的键需要使用 n 项来评估多项式({ {1}})。

如果空间要求仍然太高,即使是虚拟内存,那么您需要将大部分结构存储在磁盘上,例如B+ trees允许。在这种情况下,B +树将提供哈希表下的实现。当然,这会导致相当大的性能损失,但一旦内存要求达到一定水平,这是不可避免的。

  

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

以这种方式减少潜在数组索引的数量是完全可能的。除了使用专门的数据结构之外,您还可以执行此操作。例如,这将减少trie中节点的扇出,减少空指针的数量。

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

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

  

最后,我正在考虑多线程评分功能。

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

根据您的评论,多线程评分功能可能不需要锁定以进行只读访问。只要只读访问不会改变结构本身,遍历结构的所有状态都完全包含在read函数中,read函数调用的任何函数(例如散列函数)都是线程安全的,整个结构适合于可用内存,如果多个线程同时从树中读取,则不应该发生冲突。

如果您使用磁盘支持的方法(例如使用B +树),则最后一个要求将无法保留。在这种情况下,您可能需要锁定处理磁盘块的代码,以防止颠簸。

答案 1 :(得分:1)

trie可能与您的方法一样快(n个数组查找与n个树节点遍历)并节省大量空间。哈希也可以工作,查找速度可能更快,但需要更多空间。