文本编辑器内部文本存储：最佳块大小？

它似乎很明显，实施通用的文本编辑器（由通用我的意思是，例如当它不一定能够处理大文件（100-200 MB（这仍然是很多，而且是更就像一个“一般情况”的极端例子）），仅仅将文本存储在一个连续的长缓冲区中是不可行的，因为性能将会吸引插入/删除。文本编辑器内部文本存储：最佳块大小？

尽管有很多方法解决这个问题，他们都是围绕着这样一个事实，即你必须将文本分成块，所以我的问题是：考虑到今天的计算机能力，最佳块大小是多少？文本缓冲区的实际大小是多少实际上开始变得太大而无法存储在简单的连续缓冲区中？当代计算机在移动大块字节时速度有多快？（为了清楚起见，我们只是说不能使用间隙缓冲区，每个区块都将是一个简单的连续阵列。）

来源

2012-05-13 Cray

典型的消费系统可以在DDR3内存上实现10到30GB/s的原始内存吞吐量。这是一种基数。

从我的经验，我认为它是安全的假设，你会看到在Java中没有什么问题，实现大约100 MB内存操作每秒（C++大概可以做4-8倍之多）。从这看起来，如果缓冲区大小为64kb，那么您可以每秒执行2^10次操作，并且仍然可以。

来源

2012-05-13 19:31:13

在Eclipse中几乎所有的编辑器都是使用GapTextStore实现的，所以它们只依赖单个缓冲区只有一个加盖。

的JaveDoc为GapTextStore状态有趣的部分：

实现的缝隙管理文本存储。差距文本存储依赖于对文档的连续更改共存的假设。间隙的开始始终移至最后更改的位置。

性能：打字风格的变化在固定时间内，除非重新分配变得必要执行。通常，不会导致重新分配的更改最多只会导致一次大约d的长度的阵列拷贝操作，其中d是距前一次更改的距离。假设a（x）是长度为x的数组拷贝操作的算法性能，那么这样的变化然后在O（a（x））中执行，get（int，length）在O（a（长度））中执行，（int）在O（1）中。

如何频繁的阵列需要重新配置是由构造函数的参数来控制。

来源

2012-05-13 19:05:26

你应该在data structure known as a "rope"（绳子是一种当然的重量级字符串）读了。原始SGI STL had them以及字符串，虽然他们没有进入C++标准库，Gnu has them as an extension。

请注意，“块大小”在实现（notes）中不会像这样出现，这更多地是以懒惰的功能方式执行操作。

来源

2012-05-13 20:33:59 timday

好喜欢我写的，有可以有效地处理这些数据结构的数量，他们都（是的，绳索太）在其实现了“块大小”。唯一的另一种选择是使每个绳索段只包含一个字符/元素，我无法想象任何实现都是低效的。当然，当你拿着现有的图书馆时，你不会考虑这些细节。但是我想知道自己的低层实现的最佳块大小是多少。 – Cray

只是为了澄清一下，绳子中可能没有“设置”叶片尺寸，并且都是动态的，但最终绳子必须重新平衡，并且会有一些记忆移动，重新分配等等。上下文块大小同样重要。 – Cray

文本编辑器内部文本存储：最佳块大小？

回答

相关问题