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

Question

显然，在实现通用文本编辑器时（通用我的意思是，例如它不必处理大文件（超过100-200 MB（仍然很多，并且是更像是“一般情况”的极端例子）），将文本存储在一个连续的长缓冲区中是不可行的，因为在插入/删除时性能会很糟糕。

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

Answer 1

在Eclipse中，几乎所有编辑器都是使用GapTextStore实现的，因此它们只依赖于单个缓冲区和单个缓冲区。

GapTextStore状态的JaveDoc的有趣部分：

  

实现管理文本商店的差距。间隙文本存储依赖于对文档的连续更改位于同一位置的假设。差距的开始始终移动到最后一次更改的位置。

     

性能：除非需要重新分配，否则打字式更改会在固定时间内执行。通常，不会导致重新分配的更改将导致最多一个长度约为d的arraycopy操作，其中d是与先前更改的距离。设a（x）为长度x的arraycopy操作的算法性能，然后这样的改变然后在O（a（x））中执行，get（int，length）在O（a（长度））中执行，得到（int）in O（1）。

     

数组需要重新分配的频率由构造函数参数控制。

Answer 2

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

根据我的经验，我认为可以安全地假设您在Java中看不到每秒大约100 MB内存操作的问题（C ++可能会达到4-8倍）。从那看起来，似乎缓冲区大小为64kb，你可以达到每秒2 ^ 10次操作，但仍然可以。

Answer 3

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

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