处理超大字符串的选项

我有一个C＃程序，它使用生成语法生成树木，花朵和类似有机实体的3D模型（有关L-Systems的更多信息，请参阅wikipedia entry） - 当我生成一棵带叶子的大树，我（预计）会在字符串中呈现指数级增长，如果我愿意的话，它可以达到100的演出。处理超大字符串的选项

约束条件 - 我必须在C＃中执行此操作（C++） - C++ /本机端正忙于编译和渲染相当庞大的几何图形。

所以StringBuilder是正确的 - 即使它可以处理它，我没有足够的内存！

我不想做一个纯粹的基于文件的解决方案 - waaaaaayyyyyyyy toooooooooooo sloooooooooooowwww！

我不能改变语法 - 我意识到我可以压缩标准的L-Systems符号，但它是一个语境敏感的语法，所以一旦你得到了它的工作，你就会变得非常迷信摆弄它。

事情我已经考虑

内存映射文件 - 我不介意使用P/Invoke去的原生层来支持的事情，我只是不想重写整个生产系统中C++ - 但我还没有发现很多方便的C＃库访问此功能的方式

低级别的内存管理/页错误等 - 但是，嘿，如果我这样做，我不如卖掉它作为产品 - 使缓慢纯文件为基础的解决方案不看起来这样一个坏主意

任何人有什么想法吗？如何有效地遍历/操作/扩展生产语法生成的多字符串？

来源

2010-08-22 Mark Mullin

您可能会详细介绍一下您所做的字符串操作。只需追加写入？随机读取/写入？在一个块中随机读取/写入？随着数据的大小，你显然需要在磁盘上存储一些东西，但是你想在RAM中保留一个工作集？你如何识别工作集？我假设一个数据库不适合这种操作。 – 2010-08-22 18:44:10

这是一个生产系统 - 整个字符串被处理，并且被识别的子字符串被替换为它们的新作品数据库将是'有问题的' 它实际上是一个巨型图灵机 - 我需要在RAM的头部保留什么，但否则可以将其打开和关闭磁盘 – 2010-08-23 02:13:39

有风险陈述明显，让我抛出一个可能性：压缩。这些自引用结构本质上是可压缩的。或许，不是使用替换来显式替换扩展后的段，您可以使用一种表示，让您只需引用扩展，从而允许根据需要重新使用该引用。这似乎是有一个应用程序只使用TB来绘制一片叶子的唯一选择。 – 2010-08-23 02:53:01

你说的很对，典型的压缩方法涉及预先存在的明文的概念。我在这里讨论的是类似于使用trie data structure而不是字典的想法。它不仅仅是被动压缩，而是使用一种固有的更紧凑的表示形式，隐含地编码冗余。如果你今天的性能达到100G，那么你的性价比就会超出负担得起的硬盘的限制，所以你可能会从重新思考解决方案中受益。

来源

2010-08-24 12:39:16

请注意，Daniel对内存映射文件的回答是对我的补充。 – 2010-08-24 16:06:41

如果你可以升级到.net 4.0然后你可以使用内存映射文件，而无需P/Invoke。

http://msdn.microsoft.com/en-us/library/dd997372.aspx

来源

2010-08-22 18:42:22

谢谢！ - 正在使用.net 4，不知道 – 2010-08-23 02:14:01

如果您正在处理100G范围内的大量数据，那么 - 无论是否 - 您正在处理内存映射和分页。既然你不愿意把这个烂摊子卸载到数据库上，那么你也可以在这个级别上解决这个问题。 – 2010-08-23 02:49:19

如果这只是为你的开发机，然后是“回到未来”的解决方案可能是一个RAM Disk，又名RAM驱动器。

RAM磁盘或RAM驱动器是一块RAM（主存储器或易失性存储器），计算机软件将其看作是内存是磁盘驱动器（辅助存储器）。

例如一个product。搜索RAM磁盘或RAM驱动器，你会得到一个选择的聚宝盆。

来源

2010-08-22 19:26:39 JustBoo

100 GB不适合RAM驱动器。 – 2010-08-22 19:58:33

那你有没有过来？寻呼系统，无论是否喜欢，都可能在你的未来。 :-) – JustBoo 2010-08-22 20:27:51

处理超大字符串的选项

回答

相关问题