这是我迄今为止的进展的总结：
谷歌搜索找到了这个链接到原始代码并引用来源的小报告：
菲利普·盖奇，题为“一种新算法”
对于数据压缩'，出现了
在《C 用户日志》中 - 二月
1994年版。
多布斯博士网站上的代码链接已损坏，但该网页镜像了它们。
该代码使用hash表来跟踪缓冲区中每次传递所使用的有向图及其计数，以避免每次传递时重新计算新的。
我的测试数据是enwik8来自哈特奖.
|----------------|-----------------|
| Implementation | Time (min.secs) |
|----------------|-----------------|
| bpev2 | 1.24 | //The current version in the large text benchmark
| bpe_c | 1.07 | //The original version by Gage, using a hashtable
| bpev3 | 0.25 | //Uses a list, custom sort, less memcpy
|----------------|-----------------|
bpev3创建所有有向图的列表；块的大小为 10KB，通常有 200 个左右的有向图高于阈值（4 个，这是我们可以通过压缩获得一个字节的最小数量）；对该列表进行排序并进行第一次替换。
随着替换的进行，统计数据也会更新；通常，每次传递仅更改大约 10 或 20 个二合字母；这些被“绘制”并排序，然后与有向图列表合并；这比每次遍历都对整个有向图列表进行排序要快得多，因为该列表是nearly sorted.
原始代码在“tmp”和“buf”字节缓冲区之间移动； bpev3 只是交换缓冲区指针，这仅需要大约 10 秒的运行时间。
鉴于 bpev2 的缓冲区交换修复将使穷举搜索与哈希表版本保持一致；我认为哈希表的价值值得商榷，而列表对于这个问题来说是更好的结构。
但它仍然是多通道的。因此它不是一个普遍具有竞争力的算法。
如果你看一下大文本压缩基准，原来的bpe已添加。由于它的块大小较大，因此它在 enwik9 上的性能比我的 bpe 更好。此外，哈希表和我的列表之间的性能差距更接近 - 我将其归结为march=PentiumProLTCB 使用的。
当然也有适合和使用的场合；Symbian使用它来压缩 ROM 映像中的页面。我推测 Thumb 二进制文件的 16 位性质使其成为一种简单且有益的方法；压缩在PC上完成，解压在设备上完成。
