这是到目前为止我的进步的总结：

Googling
发现了这个链接到原始代码的小报告，并引用了源代码：

菲利普·盖奇（Philip Gage）题为“一种新的数据压缩算法”，出现在1994年2月版的《 The C Users Journal》中。

Dr Dobbs网站上的代码链接已断开，但该网页反映了它们。

该代码使用 哈希 表来跟踪缓冲区中每次通过的使用的有向图及其计数，从而避免了重新计算每次通过时的新鲜度。

我的测试数据是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个有向图；将这些“绘画”并排序，然后与有向图列表合并；这比每次通过总是对整个有向图列表进行排序要快得多，因为列表
几乎被 排序了。

原始代码在“ tmp”和“ buf”字节缓冲区之间移动；bpev3只是交换缓冲区指针，仅运行时就价值约10秒。

鉴于对bpev2的缓冲区交换修复将使详尽搜索与哈希表版本保持一致；我认为哈希表是可以争论的值，并且列表是解决此问题的更好结构。

它的门槛多通不过。因此，它不是一种普遍竞争的算法。

如果您查看大文本压缩基准，则已添加了原始bpe。由于块大小较大，因此它的性能比我在enwik9上的bpe更好。而且，哈希表和我的列表之间的性能差距更小-
我将其归结为march=PentiumProLTCB使用的。

当然，在某些场合它是合适的和被使用的。Symbian使用它来压缩ROM映像中的页面。我推测Thumb二进制文件的16位性质使其成为一种简单而有益的方法。压缩是在PC上完成的，解压缩是在设备上完成的。