我有一些数据，我正在使用自定义压缩器进行压缩，压缩数据很好，但压缩器需要很长时间，我正在寻求关于如何更快地实现这一点的建议。让我告诉你所有的细节。
输入数据是一个字节数组，最多2 ^ 16个。由于数组中的那些字节NEVER假设值介于0x08和0x37之间（包括端点），我决定将其用于简单的LZ类压缩方案，该方案通过替换任何已找到的长度为4到51字节的序列来工作。发现在“低地址”（我的意思是更靠近数组的开头），在0x08到0x37范围内有一个字节，然后是两个字节，用于寻址序列开头索引的低字节和高字节，从而为解压缩器提供原始数据的长度（在该单个字节内）和地址，以重建原始数组。
压缩器以这种方式工作：对于51到4个字节的任何长度的任何序列（我先测试更长的序列）从任何索引开始（从左到右）我检查是否存在对应的“左”，即指的是低于的索引，而不是我正在检查的起点。如果有多个匹配，我选择“保存”更多的匹配，这意味着从最左边的位置开始的时间越长。
结果只是完美 ...但当然这是过度杀戮 - 它是 4 嵌套'for'循环，其中有一个memcmp（），并且现代工作站需要分钟来压缩大约20 KB的数据，这就是我寻求帮助的原因。
代码可以访问here，如果您需要偷看一眼。 “工作”从第44行开始。
当然我可以给你任何你需要的细节，这里没什么秘密（顺便说一句，以防万一......因为这个原因，我不会改变压缩方案，因为这个工作正是我需要的！ ）
提前谢谢。
答案 0 :(得分：2)
一个非常明显的一点就是你不必绕过长度，只要知道那个位置最长的匹配是什么。这不是＆＃34;搜索＆＃34;，只是为每个匹配的字符对继续扩展匹配。当它停止时，你在那个位置有最长的匹配（当然你可以强迫它在51停止，所以它不会超限）。
另一个典型的技巧是保留一个将3或4个字符的键映射到可以找到它们的偏移列表的散列映射。这样你只需要尝试有希望产生匹配的位置。这也在DEFLATE RFC一直在底部描述。