可以看到，其中大多数实现的效率是非常低的：在Xeon E5-2650处理器上，高级别的deflate大约是23Ｍb/秒，即使是GZIP也只有33Mb/秒，这大概很难令人满意。同时，快的defalte算法大概能到75Mb/秒，Snappy是150Mb/秒，而LZ4(快速，JNI实现)能达到难以置信的320Mb/秒!
　　从表中可以清晰地看出目前有两种实现比较处于劣势：Snappy要慢于LZ4(快速压缩)，并且压缩后的文件要更大。相反，LZ4（高压缩比）要慢于级别1到4的deflate，而输出文件的大小即便和级别1的deflate相比也要大上不少。
　　因此如果需要进行“实时压缩”的话我肯定会在LZ4(快速)的JNI实现或者是级别1的deflate中进行选择。当然如果你的公司不允许使用第三方库的话你也只能使用deflate了。你还要综合考虑有多少空闲的CPU资源以及压缩后的数据要存储到哪里。比方说，如果你要将压缩后的数据存储到HDD的话，那么上述100Mb/秒的性能对你而言是毫无帮助的（假设你的文件足够大的话）——HDD的速度会成为瓶颈。同样的文件如果输出到SSD硬盘的话——即便是LZ4在它面前也显得太慢了。如果你是要先压缩数据再发送到网络上的话，好选择LZ4，因为deflate75Mb/秒的压缩性能跟网络125Mb/秒的吞吐量相比真是小巫见大巫了（当然，我知道网络流量还有包头，不过即使算上了它这个差距也是相当可观的）。
 

　　总结
　　如果你认为数据压缩非常慢的话，可以考虑下LZ4（快速）实现，它进行文本压缩能达到大约320Mb/秒的速度——这样的压缩速度对大多数应用而言应该都感知不到。
　　如果你受限于无法使用第三方库或者只希望有一个稍微好一点的压缩方案的话，可以考虑下使用JDK deflate(lvl=1)进行编解码——同样的文件它的压缩速度能达到75Mb/秒。