压缩算法效率比较

zRAM内存压缩技术分析及优化方向 zRAM于2014 年进入 Linux 3.14 内核主线,本文介绍zRAM内存压缩技术分析及优化方向 阅读详情

Quick Benchmark: Gzip vs Bzip2 vs LZMA vs XZ vs LZ4 vs LZO比较了几种算法:

1. 压缩效率:LZO <GZIP < BZIP2 < LZMA

2. 压缩时间:GZIP <LZO ~= BZIP2 << LZMA

3. 解压缩时间:LZO <GZIP < LZMA<< BZIP2

4.压缩需要的内存:GZIP < LZO < BZIP2 << LZMA

5.解压缩需要的内存:GZIP < LZO < BZIP2 << LZMA

如果FLASH不是问题,启动速度是关键,选LZO。如果是在低成本嵌入式设备上,FLASH和RAM很小,GZIP是不错的选择;如果RAM有限,选BZIP2;如果RAM还够,可以考虑LZMA。

 

Selected archives

I have selected:

  • Source of the kernel to test source compression
  • Stream protocol with flush

Test conditions

Tests were run on a desktop:

  • Intel Core i5 CPU 750 at 2.67GHz
  • 8GB of DDR3 memory
  • tmpfs as ram disk is used
  • Linux kernel 3.3.2, gentoo amd64
  • CFLAGS: -pipe -O2 -g -floop-block -floop-interchange -fgraphite
  • bzip2-1.0.6-r3, xz-utils-5.0.3, gzip-1.4

Only normal mode will be tested firstly.

The file test results

Note: The first column with numbers 1..9 indicates the compression setting passed to gzip, bzip2 and lzmash (e.g. "gzip -9").

Tarball mode from linux-3.3, original size: 466083840 (445M)

Compressed file size in bytes

 gzipbzip2lzmalzma -exzxz -elz4lzop
 gzipbzip2lzmalzma -exzxz -elz4lzop
1124875819 (120M)93997047 (90M)85618192 (82M)72042179 (69M)85630688 (82M)72069084 (69M)165844264 (159M)168012430 (161M)
2119040249 (114M)87741348 (84M)81480824 (78M)70264395 (68M)81492504 (78M)70282944 (68M)165844264 (159M)166987891 (160M)
3114931686 (110M)84816957 (81MB)79575087 (76MB)69015118 (66MB)79586568 (76MB)69029204 (66MB)165844264 (159M)166987891 (160M)
5102328357 (98M)81837328 (79M)69557610 (67M)67879362 (65M)69583428 (67M)67875988 (65M)-166987891 (160M)
7100128597 (96M)80197758 (77M)67276420 (65M)66868212 (64M)67294092 (65M)66852780 (64M)-116205578 (111M)
999740486 (96M)78963640 (76M)65841213 (63M)65362226 (63M)65859432 (63M)65372696 (63M)-114824102 (110M)

Compression ratio

 gzipbzip2lzmalzma -exzxz -elz4lzop
 gzipbzip2lzmalzma -exzxz -elz4lzop
126.8%20.2%18.4%15.5%18.4%15.5%35.6%36.0%
225.5%18.8%17.5%15.1%17.5%15.1%35.6%35.8%
324.7%18.2%17.1%14.8%17.1%14.8%35.6%35.8%
522.0%17.6%14.9%14.6%14.9%14.6%-35.8%
721.5%17.2%14.4%14.3%14.4%14.3%-24.9%
921.4%16.9%14.1%14.0%14.1%14.0%-24.6%

Compression time

 gzipbzip2lzmalzma -exzxz -elz4lzop
 gzipbzip2lzmalzma -exzxz -elz4lzop
18.1s58.3s31.7s4m37s32.2s4m40s1.3s1.6s
28.5s58.4s40.7s4m49s41.9s4m53s1.4s1.6s
39.6s59.1s1m2s4m36s1m1s4m39s1.3s1.5s
514s1m1s3m5s5m3m6s4m53s-1.5s
721s1m2s4m14s5m52s4m13s5m57s-35s
933s1m3s4m48s6m40s4m51s6m40s-1m5s
  • gzip -1 vs lz4 -1 on x86: lz4 6.2x more fast
  • gzip -1 vs lz4 -1 on ARM: lz4 3.6x more fast

Decompression time

 gzipbzip2lzmalzma -exzxz -elz4lzop
 gzipbzip2lzmalzma -exzxz -elz4lzop
13.5s3.4s6.7s5.9s7.2s6.5s0.4s1.5s
23s15.76.3s5.6s6.8s6.3s0.3s1.4s
33.2s15.9s6s5.6s6.7s6.2s0.4s1.4s
53.2s16s5.5s5.4s6.2s6s-1.5s
73s15s5.3s5.3s5.9s5.8s-1.3s
93s15s5s5.1s5.6s5.6s-1.2s

Memory requirements on compression

 gzipbzip2lzmalzma -exzxz -elz4lzop
 gzipbzip2lzmalzma -exzxz -elz4lzop
10.4MB1.1MB8.3MB12.6MB8.3MB12.5MB12MB0.7MB
20.4MB1.9MB15.8MB24MB15.8MB24MB12MB0.7MB
30.4MB2.7MB30.7MB46.9MB30.8MB47M13.2MB0.7MB
50.4MB4.2MB93MB93MB93MB93MB-0.7MB
70.4MB5.7MB185MB185MB185MB185MB-0.9MB
90.4MB7.2MB672MB673MB673MB673MB-0.9MB
  • Note: lz4 it's the program using this size, the code for internal lz4 use very less memory

Memory requirements on decompression

 gzipbzip2lzmalzma -exzxz -elz4lzop
 gzipbzip2lzmalzma -exzxz -elz4lzop
10.1MB0.3MB1MB1MB1MB1MB13MB0.2MB
20.1MB0.9MB2.1MB2.1MB2.1MB2.1MB12MB0.2MB
30.1MB1.1MB4.1MB4.1MB4.0MB4.0MB13MB0.2MB
50.1MB1.9MB8.1MB8.1MB8.1MB8.1MB-0.2MB
70.1MB2.6MB16MB16MB16MB16MB-0.2MB
90.1MB3.4MB64MB64MB64MB64MB-0.2MB
  • Note: lz4 it's the program using this size, the code for internal lz4 use very less memory

Cli used for -1 compression:

  • time gzip -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;time gunzip linux-3.3.tar*
  • time bzip2 -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;time bunzip2 linux-3.3.tar.bz2
  • time lzma -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time unlzma linux-3.3.tar*
  • time lzma -e -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time unlzma linux-3.3.tar*
  • time xz -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time unxz linux-3.3.tar*
  • time xz -e -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time unxz linux-3.3.tar*
  • time /home/user/lz4-read-only/lz4demo64 -c0 linux-3.3.tar linux-3.3.tar.lz4;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time /home/user/lz4-read-only/lz4demo64 -d linux-3.3.tar.lz4 linux-3.3.tar;rm linux-3.3.tar.*
  • time lzop -1 linux-3.3.tar;rm linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time lzop -d linux-3.3.tar*;rm linux-3.3.tar.*

Stream test

Time to compress

 gzipzliblz4lz4hcnone
 gzipzliblz4lz4hcnone
137636813031110
2371391   
3378362   
5390392   
7389387   
9393384   

Time to decompress

 gzipzliblz4lz4hcnone
 gzipzliblz4lz4hcnone
1179717788097969
218411831   
317711780   
518061960   
718611851   
918351806   

Messured with:

timespec tstart,tstop;
clock_gettime(CLOCK_REALTIME, &tstart);
//compression/decompression
clock_gettime(CLOCK_REALTIME, &tstop);
compressionTime+=((quint64)tstop.tv_sec * 1000000LL + (quint64)tstop.tv_nsec / 1000LL)-((quint64)tstart.tv_sec * 1000000LL + (quint64)tstart.tv_nsec / 1000LL);

Memory used

gzipzliblz4lz4hcnone
gzipzliblz4lz4hcnone
0.5MB0.5MB0MB0MB0MB

The socket is always used as full duplex, then it's compression + decompression memory.

Compression ratio

It's transferred size/raw size (lower is better)

With the benchmark application

Uploaded at: https://github.com/alphaonex86/debug-devel/tree/master/QTcpCompressionBenchmark

gzipzliblz4lz4hcnone
gzipzliblz4lz4hcnone
0.990.971.591.591

The most over-head of small packet (3Bytes) is drop by high compression with zlib/gzip for the big packet.

Graphics

Compression-ratio.png Compression-time.png

Quick benchmark on ARM64

A quick benchmark on ARM64 (odroid, Cortex A53), on kernel Image (12MB), use default compression level (-6) because no way to configure the compression level of btrfs

The speed is on compressed stream, mean the hdd.

 xzgziplz4zstd
Size4.2M5.5M7.8M5.8M
Compression speed0.2 MB/s1.8 MB/s21.4 MB/s2.8 MB/s
Decompression speed4.8 MB/s13.6 MB/s48.4 MB/s19.1 MB/s
用哈希表优化的lz77压缩算法的实现 最近终于有空研究研究E*F的K*KYU2。和预料到的一样仍然是广泛使用LZ77,而且是毫不改变地使用LZ77……但是,时代进步了, 图片文件都是真彩色的了,大小变大了3倍,仍然使用LZ77的代价就是速度……大家都知道LZ77的特点就是解压超快,压缩巨慢(不然就不会有LZW这种 不伦不类的算法出来了……)在png的相关网站上查找了一下优化方案,自己写了一下优化代码,虽然目前速度仍然不能很让人满意(在 阅读详情

相关推荐

Linux内存从0到1学习笔记(11.2 内存优化方案之内存压缩zram)

zram是Linux内核提供的一种虚拟内存压缩功能,通过在将一部分内存模拟成块设备,并将压缩后的内存写到这部分模拟的块设备中,直到必须使用硬盘上的交换空间,zram 本质是就是一个块设备。

从0到1,突破自己 1万+

zram lz4 和 lzo 算法性能评估比较

本次评估是基于高通660 平台,Arm 64 位处理器,其中有 8 个核,4个小核 1.8G 频率,4个大核 2.2G 频率 ,主要对比 zram 的两个主流的压缩算法的性能差别。由于前段时间在看工作中发现这个平台默认只使用 lzo,但在社区上早就有了 lz4 的算法,且性能要比 lzo 算法在读方面要好 3 倍,于是就搜了一下 lz4 的压缩算法在 arm 平台上的实际表现,可惜资料很少

qkhhyga2016的博客 3万+

快速无损压缩算法性能比较

几个常用快速无损压缩算法性能比较_追梦人_新浪博客

几种压缩算法的压缩和速度比较 LZ4太快了

Quick Benchmark: Gzip vs Bzip2 vs LZMA vs XZ vs LZ4 vs LZO EDIT: Add zstd Contents  [hide]  1 Selected archives2 Test conditions3 The file test results 3.1 Compressed

leilonghao的博客 8万+

Kubernetes多网卡环境下Calico网络配置避坑指南:如何精准指定业务网卡

本文针对Kubernetes多网卡环境下Calico网络配置的常见痛点,提供了精准指定业务网卡的实战指南。通过深入分析Calico的IP自动检测机制,详细解读并对比了五种IP_AUTODETECTION_METHOD配置方法(如interface、cidr、can-reach等),帮助运维人员从根源上解决网络分区和Pod通信失败问题,确保生产集群网络的稳定与可靠。

weixin_28835551的博客 729

Python爬虫案例:从39问医生网爬取口腔科的在线问答记录(单轮问答)

本次实验爬取39问医生网中口腔科分类下的所有在线单轮问答记录,每页32条,共100页,总数据量为3200条,最终结果以excel格式保存。

JieBao11的博客 1640

各种压缩算法的压缩效率,时间、压缩比等比较

测试办法:同样的文件StatLogInfo_1409070030_125.log大小为60520K,采用不同的压缩方法。 zip花费17362毫秒,压缩后大小为10806K gzip花费2103毫秒,压缩后大小为11209K 7z花费14109毫秒,压缩后大小为3842K snappy花费1571毫秒,压缩后大小为21347K winrar压缩后大小为4968K【没有公布算法】 结论: 压缩比排序 7z > winrar > zip > gzip > snappy 压缩速度 snap

玩火的稻草人的博客 1万+

数字IC面试核心:从MUX基础到Glitch-Free时钟切换电路深度剖析

本文深入剖析数字IC设计中的MUX基础原理及其在Glitch-Free时钟切换电路中的应用。从二选一MUX的门级实现到时钟切换中的毛刺问题,详细讲解了同步切换机制和工程优化技巧,帮助工程师掌握高速时钟电路设计的核心要点。

weixin_42629815的博客 323

java压缩算法

为什么80%的码农都做不了架构师?>>> ...

weixin_34236869的博客 283

Linux实战:rMATS可变剪切分析从零到一,避坑指南与结果深度解析

本文详细介绍了在Linux系统上从零开始部署rMATS进行可变剪切分析的完整流程,包括环境搭建、安装避坑指南、参数优化及结果解读。特别针对gfortran依赖、数学库配置等常见问题提供解决方案,并深入解析JC与JCEC结果的差异及可视化技巧,帮助生物信息学研究者高效完成可变剪切分析。

weixin_30394669的博客 408

未隔离电源设备使用usb转串口调试导致串口模块爆炸烧坏事故记录

这个事就发生在前两天,我们公司的wifi模块被客户用到了咖啡机上,客户寄了一台整机给我们协助调试,还送了几包咖啡豆,本想着还能打个咖啡喝一喝的,但就在咖啡机刚寄过来第一天,就出事了。而这个事故的发生,竟然仅仅是因为同事接了个串口模块到电脑调试打印导致的。谁也想不到,这个3.3V的供电的wifi模块居然还有这么大的威力。直接将usb转TTL串口模块的转换芯片给爆开了,咖啡机也给弄坏了,据同事描述当时情况就只见到一片火光和一声巨响,状况比较惨烈,所幸的是笔记本电脑没有烧坏,但是直接给崩蓝屏了。 ...

fangye945a的博客 6188

Kafka 生产者压缩算法有哪些?

前言 本文隶属于专栏《大数据技术体系》,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢! 本专栏目录结构和参考文献请见大数据技术体系 关联 数据压缩算法该如何选择? WHY 压缩? 数据压缩显著地降低了磁盘占用或带宽占用,从而有效地提升了 I/O 密集型应用的性能。 不过引入压缩同时会消耗额外的 CPU 时钟周期,因此压缩是 I/O 性能和 CPU 资源的平衡。 producer 压缩,broker 压缩,consumer 解压 Kafka 自 0.7.x 版本便开始

Shockang的博客 2171

基于Simulink的MIMO-OFDM系统仿真建模示例

MIMO概述MIMO技术利用多个天线进行信号发送和接收,通过空间复用来提高数据传输速率,或通过空间分集来增强信号的可靠性。OFDM概述OFDM是一种将高速率数据流分成多个低速数据流并行传输的技术,每个子载波都采用调制方式(如BPSK、QPSK),并通过IFFT/FFT变换实现串并转换。MIMO-OFDM优势结合了MIMO的空间分集增益与OFDM对抗多径效应的能力,适用于宽带无线通信系统。提供了更高的数据速率和更好的频谱效率,是现代无线通信标准(如4G LTE、5G NR等)的核心技术之一。

xiaoheshang_123的博客 327

hadoop当中支持的压缩算法

文件压缩有两大好处,节约磁盘空间,加速数据在网络和磁盘上的传输 前面hadoop的版本经过重新编译之后,可以看到hadoop已经支持所有的压缩格式了,剩下的问题就是该如何选择使用这些压缩格式来对MapReduce程序进行压缩 可以使用bin/hadoop checknative 来查看编译之后的hadoop支持的各种压缩,如果出现openssl为false,那么就在线安装一下依赖包 bin/ha...

写的不好之处,请指教 5817

【stata基础代码大全 】 可独立完成一篇实证

用stata打开,直接替换自己需要的变量就行,小白友好❗️❗️❗️。八、八.中介效应检验:路径分析(三种方法)第二种方法即Sobel-Goodman检验。*(7)Winsor处理,剔除异常值。六、内生性问题解决方法(附具体模型)其三,工具变量:两阶段最小二乘。第三种方法即Bootstrap检验。二、Stata中数据的基本处理。*(5)生成行业、年度虚拟变量。PSM1————近邻匹配。七、调节效应检验:机制分析。*(2)剔除数据中的样本。*(4)给变量添加标签。*(3)生成新的变量。*(6)基本数据匹配。

J_Giser的博客 8023

TSN新技术,让您的设备网络“更实时、更确定、更安全”

近日,工业和信息化部发布了2022年第23号公告,批准发布行业标准YD/T 4134-2022《工业互联网时间敏感网络需求及场景》。该标准是国内首个时间敏感网络(TSN)技术标准,标志着我国TSN技术标准体系建设迈出了坚实的一步,对构建工业互联网网络标准体系具有重要意义。TSN源于Time-Sensitive Networking的缩写,中文译名为时间敏感网络,因其具备的确定性和微秒级交互特性,受到了对实时性要求较高的工业控制领域的关注。TSN与工业数智化。

创龙,嵌入式一体化解决方案商 770

突破存储瓶颈:Quickwit中ZSTD与LZ4压缩算法的终极对决

在当今数据爆炸的时代,日志和追踪数据的存储成本正成为企业IT预算的沉重负担。根据IDC预测,全球数据量将从2023年的120ZB增长到2025年的180ZB,其中非结构化数据占比超过80%。作为亚秒级云原生搜索引擎,Quickwit面临着一个关键挑战:如何在保持高性能查询的同时,最大限度降低云存储成本。本文将深入剖析Quickwit的数据压缩策略,通过实测对比ZSTD与LZ4两种算法的性能表现,为...

gitblog_00404的博客 475

VC中sqlite的使用

在VC中对sqlite的使用,实现数据库大批数据的快速插入,读取数据库中的数据在ListCtrl中显示

reqwest压缩算法终极测评:gzip/brotli/zstd谁是性能之王

你还在为API响应速度慢而头疼?还在纠结该选择哪种压缩算法?本文将通过实测数据告诉你,在reqwest中如何选择gzip、brotli和zstd压缩算法,让你的HTTP请求效率提升50%以上! 读完本文你将获得: - 三种主流压缩算法的性能对比 - reqwest中启用压缩的正确姿势 - 不同场景下的压缩算法选型建议 - 性能优化实战代码示例 ## 压缩算法简介 HTTP压缩是提升网络传输效...

gitblog_00044的博客 891

复分析 阿尔福斯(Ahlfors) 第三版答案 英文

答案分为十章,有部分习题没有答案,全英文复分析阿尔福斯(Ahlfors) 第三版答案

SIMATIC S7-1200, S7-1500 PID 控制[手册]

SIMATIC S7-1200, S7-1500 PID 控制[手册]

kafka 生产者压缩算法

kafka消息分区机制 为什么要压缩如何压缩何时压缩何时解压缩各种压缩算法对比 为什么要压缩   压缩是一种时间换空间的动作。具体来说就是用CPU时间去换取磁盘空间或网络I/O传输量,希望以较小的CPU开销带来更少的磁盘占用或者更少的网络I/O传输。 如何压缩   要搞清楚kafka如何压缩消息。就要从kafka的消息格式说起。目前kafka的有两大类消息格式:V1版本和V2版本。   无论是那个版本,kafka的消息层次都是两层:消息集合以及消息。一个消息集合中包含若干条日志项,而日志项才是真正封装消息的

wangdawei_的博客 1836

KafkaJS压缩算法对比:GZIP、Snappy、LZ4、ZSTD性能指南

Apache Kafka是一个高性能的分布式消息系统,而**KafkaJS压缩算法**在数据传输和存储中起着至关重要的作用。作为Node.js的现代Kafka客户端,KafkaJS支持多种压缩算法,包括GZIP、Snappy、LZ4和ZSTD,每种算法都有其独特的性能特征和适用场景。 ## 为什么需要Kafka压缩算法? Kafka压缩算法能够显著减少网络带宽使用和存储空间需求。对于高吞吐量的

gitblog_00276的博客 959

实用干货分享(5)- Hive存储格式及压缩算法测试比对分析

Hive文件存储格式及优缺点textfile默认的文件格式,行存储。建表时不指定存储格式即为textfile,导入数据时把数据文件拷贝至hdfs不进行处理。优点:最简单的数据格式,便于和其他工具(pig, grep, sed, awk)共享数据、便于查看和编辑;加载较快。缺点:耗费存储空间,I/O性能较低;Hive不进行数据切分合并,不能进行并行操作,查询效率低。适用于小型查询,查看具体数据内容的测试操作。sequencefile行存储,含有键值对的二进制文件。优点:可压缩、可分割,优化磁盘利用率和I/O;

zhongdianjinxin的博客 571

[原创]用哈希表优化的lz77压缩算法的实现

 最近终于有空研究研究E*F的K*KYU2。和预料到的一样仍然是广泛使用LZ77,而且是毫不改变地使用LZ77……但是,时代进步了,图片文件都是真彩色的了,大小变大了3倍,仍然使用LZ77的代价就是速度……大家都知道LZ77的特点就是解压超快,压缩巨慢(不然就不会有LZW这种不伦不类的算法出来了……)在png的相关网站上查找了一下优化方案,自己写了一下优化代码,虽然目前速度仍然不能很让人满意(

superarhow的专栏 8539

gzdeflate gzcompres gzencode 比较

输入文件大小:36M gzdeflate 输出文件大小 13404 (KB)    压缩所用时间:3.54S gzcompress 输出文件大小13592(KB)   压缩所用时间:2.5895 S gzencode 输出文件大小 13964(KB) 压缩所用时间:3.396S gzdecode (No version information availa...

Oracle PHP JS 学习笔记 273

300%性能差距:DuckDB三大压缩算法Zstd/Snappy/LZ4深度测评

你是否在处理Parquet文件时遇到过两难选择:用Zstd压缩率高但速度慢,选Snappy速度快却浪费存储空间?本文通过DuckDB实测数据,一文解决OLAP场景下的压缩算法选型难题。读完你将获得: - 三种算法在不同数据类型下的性能对比 - 基于DuckDB基准测试的最优配置方案 - 生产环境部署的实战建议 ## 压缩算法家族与DuckDB实现 DuckDB作为嵌入式OLAP数据库,在[th...

gitblog_00766的博客 564

lz78压缩算法c语言实现,著名压缩算法(LZ78)的缓慢实现

我想我可以做得更好(对不起,有点长):import java.io.File;import java.io.FileInputStream;import java.util.HashMap;import java.util.HashSet;import java.util.Map;import java.util.Set;import java.util.concurrent.ExecutorSe...

weixin_34442022的博客 642

Java不同压缩算法的性能比较

本文将会对常用的几个压缩算法的性能作一下比较。结果表明,某些算法在极端苛刻的CPU限制下仍能正常工作。 文中进行比较的算有: ●JDK GZIP ——这是一个压缩比高的慢速算法,压缩后的数据适合长期使用。JDK中的java.util.zip.GZIPInputStream / GZIPOutputStream便是这个算法的实现。 ●JDK de

benpaobagzb的博客 498
上一篇: C和C++混合编译,extern"C"的用法
下一篇: Hex、bin、axf、elf格式文件小结
evilcode
博客等级 码龄20年 307粉丝 16原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值