我想知道，是否有任何更快的 zlib 构建版本以及更高级的优化？
如果可以使用 SSE 指令或 Intel C++ 编译器对其进行优化，或者使用一些早期获得专利的技巧（我知道专利是 gzip/zlib 开发期间的一个严重限制），有没有人愿意去实现它？
我对压缩速度特别感兴趣，这对提供静态和动态内容的高性能网络服务有直接影响。
答案1
在第一次提出这个问题几年后，出现了一些更快的 x86_64 zlib，使用了 BarsMonster 建议的优化类型：
samtools（一套用于与高通量测序数据交互的工具）的作者制作了一个zlib 速度比较。
zlib-ng 收集主线 zlib 中没有的 zlib 优化但它可能不如主线 zlib 稳定。其问题跟踪器也具有指导意义，可作为其他已知 zlib 加速的参考。
最近拉取请求声称“在 x86_64 上将 inflate_fast 速度提高 1.5 倍”（通过一次填充和复制 8 个字节） 已经制作但未被接受进入主线 zlib。提供这项工作的补丁在被 Chromium 接受的过程中也经历了坎坷（参见此铬虫和Chromium 评论) 但希望提交者能休息一下，走开并重新充电，因为从远处看，在复杂的情况下进展似乎非常缓慢......
最近，自由的自由是经过高度优化的重写版本，可生成/混淆 zlib 兼容的输出/输入，但不提供 zlib 兼容的 API。在撰写本文时，它拥有 zlib 速度王冠。
答案2
另一种选择是迷你兹库（公共域，unlicense.org），它在单个 C 源文件中实现大部分 zlib API，并读取/写入与 zlib 兼容的压缩数据流。在压缩级别 1 下，它使用实时压缩器，速度极快（比 minilzo 稍慢，但压缩率更高）。
答案3
不是重建，但有两个很好的 zlib 替代方案：quicklz 和 fastlz。与 gzip -1 相比，这两个方案都非常快，但压缩率没有那么好。对于我的应用程序，大小增加了 10-15%，但压缩速度提高了 6 倍，因此这是一个非常好的权衡。
当然，两者都不兼容 zlib，所以可能不适合您。