在实现通用文本编辑器时（例如，我的意思是通用的意思是它不必能够处理大文件（超过 100-200 MB（这仍然很多，并且是更像是“一般情况”的极端示例）），仅将文本存储在一个连续的长缓冲区中是不可行的，因为插入/删除会降低性能。
虽然有很多方法可以解决这个问题，但它们都围绕着这样一个事实，即您必须将文本分成块，所以我的问题是：考虑到当今的计算机能力，最佳的块大小是多少？文本缓冲区的实际大小实际上开始变得太大而无法存储在简单的连续缓冲区中？现代计算机在移动大块字节方面有多快？ （为了清楚起见，我们只说不能使用间隙缓冲区，每个块将是一个简单的连续数组。）
【问题讨论】：
标签： performance text data-structures x86 buffer
在 Eclipse 中，几乎所有的编辑器都是使用 GapTextStore 实现的，因此它们只依赖于一个带有单个 gab 的缓冲区。
GapTextStore 的 JaveDoc 中有趣的部分指出：
实现间隙管理文本存储。间隙文本存储依赖于对文档的连续更改位于同一位置的假设。间隙的起点始终移动到最后一次更改的位置。
性能：除非需要重新分配，否则键入样式的更改会在恒定时间内执行。一般情况下，不引起重新分配的更改最多会引起一次长度约为 d 的 arraycopy 操作，其中 d 是与上一次更改的距离。设 a(x) 为长度为 x 的数组复制操作的算法性能，然后这样的变化在 O(a(x)) 中执行，get(int, length) 在 O(a(length)) 中执行，得到(int) 在 O(1) 中。
数组需要重新分配的频率由构造函数参数控制。
【讨论】：
典型的消费系统可以在 DDR3 内存上实现 10 到 30 GB/s 的原始内存吞吐量。那是一种基数。
根据我的经验，我认为可以安全地假设在 Java 中实现每秒大约 100 MB 的内存操作没有问题（C++ 可能可以做到 4-8 倍）。由此看来，如果缓冲区大小为 64kb，您可以每秒进行 2^10 次操作，但仍然可以。
【讨论】：
您应该阅读data structure known as a "rope"（绳索当然是一种重量级的绳子）。原始的 SGI STL had them 以及字符串，虽然它们没有进入 C++ 标准库，但 Gnu has them as an extension。
请注意，“块大小”在实现 (notes) 中并没有这样显示，这更多是关于以一种懒惰、实用的方式做事。
【讨论】：