LZO说明
摘要
LZO 是一个用 ANSI C 语言编写的无损压缩库。他能够提供非常快速的压缩和解压功能。解压并不需要内存的支持。即使使用非常大的压缩比例进行缓慢压缩出的数据,依然能够非常快速的解压。LZO 遵循 GNU 的 GPL 使用许可。
介绍
LZO 非常适合进行数据的实时压缩解压处理,这就是说他更关心操作速度,而不是压缩比例。
LZO 使用 ANSI C 语言编写,并且压缩后的数据也被设计为可以跨平台使用的格式。
LZO 拥有如下的特点:
- 解压速度很快,并且很简单;
- 解压时不需要内存支持;
- 压缩的速度还不错;
- 压缩时只需要 64 KiB 的内存支持;
- 压缩比例可以根据需要调节,而这并不影响解压的效率,提高压缩比例自然会降低压缩速度;
- 压缩包含了很多的压缩级别,提供很多选择;
- 提供只需要 8 KiB 内存支持的压缩级别;
- 提供线程安全;
- 提供无损压缩;
LZO提供多重压缩,和复原解压;
设计标准
LZO 以处理速度为原则设计。解压速度要快于压缩速度。能够提供给任何程序实时解压的功能。LZO1X的解压是按照 i386 编码优化的。
事实上,是通过解压算法定义的压缩数据结构,最后采用手工测试数据验证了这个结构。
效果
在古老的 Pentium 133 的设备上,我们运行了 Calgary Corpus 的测试数据。数据采用了 256 KiB的大小。
LZOxx-N 定义了使用的算法名称,N代表压缩级别。1-9 级别使用 64 KiB 内存,他主要提供更快的压缩速度。99 级别使用 256 KiB 内存,提供更大的压缩比例,但是处理速度依然很快。999 级别是按照压缩比例优化的算法,他的压缩速度很慢,并且使用大量的内存,这种级别一般用于生成预压缩数据。
C 语言版本的 LZO1X-1 算法要比最快的 ZLIB 压缩级别,快4-5倍的速度。当然他也在压缩比例、压缩时间、解压时间方便优于 LZRW1-A 和 LZV 这些算法。
+------------------------------------------------------------------------+ | Algorithm Length CxB ComLen %Remn Bits Com K/s Dec K/s | | --------- ------ --- ------ ----- ---- ------- ------- | | | | memcpy() 224401 1 224401 100.0 8.00 60956.83 59124.58 | | | | LZO1-1 224401 1 117362 53.1 4.25 4665.24 13341.98 | | LZO1-99 224401 1 101560 46.7 3.73 1373.29 13823.40 | | | | LZO1A-1 224401 1 115174 51.7 4.14 4937.83 14410.35 | | LZO1A-99 224401 1 99958 45.5 3.64 1362.72 14734.17 | | | | LZO1B-1 224401 1 109590 49.6 3.97 4565.53 15438.34 | | LZO1B-2 224401 1 106235 48.4 3.88 4297.33 15492.79 | | LZO1B-3 224401 1 104395 47.8 3.83 4018.21 15373.52 | | LZO1B-4 224401 1 104828 47.4 3.79 3024.48 15100.11 | | LZO1B-5 224401 1 102724 46.7 3.73 2827.82 15427.62 | | LZO1B-6 224401 1 101210 46.0 3.68 2615.96 15325.68 | | LZO1B-7 224401 1 101388 46.0 3.68 2430.89 15361.47 | | LZO1B-8 224401 1 99453 45.2 3.62 2183.87 15402.77 | | LZO1B-9 224401 1 99118 45.0 3.60 1677.06 15069.60 | | LZO1B-99 224401 1 95399 43.6 3.48 1286.87 15656.11 | | LZO1B-999 224401 1 83934 39.1 3.13 232.40 16445.05 | | | | LZO1C-1 224401 1 111735 50.4 4.03 4883.08 15570.91 | | LZO1C-2 224401 1 108652 49.3 3.94 4424.24 15733.14 | | LZO1C-3 224401 1 106810 48.7 3.89 4127.65 15645.69 | | LZO1C-4 224401 1 105717 47.7 3.82 3007.92 15346.44 | | LZO1C-5 224401 1 103605 47.0 3.76 2829.15 15153.88 | | LZO1C-6 224401 1 102585 46.5 3.72 2631.37 15257.58 | | LZO1C-7 224401 1 101937 46.2 3.70 2378.57 15492.49 | | LZO1C-8 224401 1 100779 45.6 3.65 2171.93 15386.07 | | LZO1C-9 224401 1 100255 45.4 3.63 1691.44 15194.68 | | LZO1C-99 224401 1 97252 44.1 3.53 1462.88 15341.37 | | LZO1C-999 224401 1 87740 40.2 3.21 306.44 16411.94 | | | | LZO1F-1 224401 1 113412 50.8 4.07 4755.97 16074.12 | | LZO1F-999 224401 1 89599 40.3 3.23 280.68 16553.90 | | | | LZO1X-1(11) 224401 1 118810 52.6 4.21 4544.42 15879.04 | | LZO1X-1(12) 224401 1 113675 50.6 4.05 4411.15 15721.59 | | LZO1X-1 224401 1 109323 49.4 3.95 4991.76 15584.89 | | LZO1X-1(15) 224401 1 108500 49.1 3.93 5077.50 15744.56 | | LZO1X-999 224401 1 82854 38.0 3.04 135.77 16548.48 | | | | LZO1Y-1 224401 1 110820 49.8 3.98 4952.52 15638.82 | | LZO1Y-999 224401 1 83614 38.2 3.05 135.07 16385.40 | | | | LZO1Z-999 224401 1 83034 38.0 3.04 133.31 10553.74 | | | | LZO2A-999 224401 1 87880 40.0 3.20 301.21 8115.75 | +------------------------------------------------------------------------+
注解:
- CxB 是块的数目;
- K/s 是每秒处理 1KB 没有压缩的数据的速度;
- 汇编的解压速度将会更快;
简单文档
LZO 是块压缩算法,他压缩和解压一个块数据。压缩和解压的块大小必须一样。
LZO 将块数据压缩成匹配数据(滑动字典)和非匹配的文字序列。LZO 对于长匹配和长文字序列有专门的处理,这样对于高冗余的数据能够获得很好的效果,这样对于不可压缩的数据,也能得到较好的结果。
在处理不可压缩数据时,LZO 将扩展输入数据,每1024个字节最大增加 64 个字节。
我已经通过类似于 valgrind 这样的内存检查工具验证过 LZO 程序,并且也使用了超过千兆字节的数据,进行各种参数调整,检查过各种潜在的问题。LZO 目前不存在任何已知 BUG。
各种算法说明
这里实现了很多的算法,但是我希望提供没有限制的向下兼容性,所以以后并不会取消现有的内容。
就像需要对象文件都是相对独立的,若通过静态链接使用 LZO 库,只会增加很少的容量(大约几KiB),以为内只要在真正使用 LZO 功能时这个模块才会被加载。
1996年3月,我在 newsgroups.comp.compression 和 comp.compression.research 公布了 LZO1 和 LZO1A。他们主要处理了兼容性的问题。LZO2A解压的速度非常慢,并且也没有能提供一个较快的压缩速度。
在我的试验中可以看到,LZO1B适合处理大量的数据,或者有高冗余性的数据。LZO1F适合处理小量数据和二进制数据。LZO1X适合各种环境。LZO1Y 和 LZO1Z 跟 LZO1X 很相像,他们能够在一些环境中达到更好的压缩比例。
请注意,你有很多的选择。
使用 LZO 库
无论数据的大小,使用 LZO 库的基本功能非常的简单。我们假设你打算使用 LZO1X-1的算法处理你的数据。
压缩
1 include <lzo/lzo1x.h> 2 call lzo_init () 3 通过 lzo1x_1_compress () 压缩你的数据 4 编译连接 LZO 库
解压
1 include <lzo/lzo1x.h> 2 call lzo_init () 3 通过 lzo1x_decompress () 解压数据 4 编译连接 LZO 库
在源码包的 examples/simple.c 有完整的范例代码。也可以查看 LZO.FAQ 获得更多内容。
原始文件:
LZO FAQ
-
我不想阅读文档,指向知道如何将这个功能添加到我的程序中
有两个范例:examples/simple.c 和 examples/lzopack.c 提供了简单使用的方法。
但是最好还是将整个的文档阅读完成,会帮助你更好的使用。
-
你能解释一下各种算法名称的含义吗?
我们用 LZO1X 来举例说明:
算法名称:LZO1X
算法分类:LZO1
然后提供了很多的压缩级别:
LZO1X-999 !---------- 算法分类 !--------- 算法类型 !!!----- 压缩级别 (1-9, 99, 999)
LZO1X-1(11) !---------- 算法分类 !--------- 算法类型 !------- 压缩级别 (1-9, 99, 999) !!---- 内存级别 (压缩时所需要的内存)
在一个压缩类型中,不同的压缩级别和内存级别的数据结构是相同的,所以 LZO1X 的解压方法,能够适用于 LZO1X-** 对应的所有压缩算法。
LZO1 分类:使用严格的 BTYE 校验的 压缩数据结构
LZO2 分类:使用 bit 位移方式,解压速度比较慢。
-
为什么有这么多的算法?
由于很多的历史版本,而我希望能够提供良好的向下兼容性,所以拥有这么多算法。不必担心整个库的大小问题,使用其中一种算法,只会给你的程序添加很少的几个 KiB。
如果你只是希望给你的程序添加一个简单的压缩功能,你可以查看 miniLZO 部分,在 minilzo/README.LZO 中,可以查看更纤细的信息。
-
我应该使用哪种算法?
LZO1X 在很多情况下都是一个比较好的选择。所以,追求速度可以使用 LZO1X-1,生成预压缩文件可以使用 LZO1X-999,如果你有很多的内存,可以使用 LZO1X-1(11) 或者 LZO1X-1(12)。
当然这里有很多的选择,你可以根据自己的需要进行选择。也可以尝试一下 LZO1Y 或者 LZO1F 等等。
-
在解压的时候,每种方式有什么区别?
我们还是使用 LZO1X 作为范例来说明:
- lzo1x_decompress
他能够提供较快的解压速度,这是一个标准的解压方式。但是他不提供附加的相关数据安全检查,他默认处理的数据是完成的压缩后数据。如果数据由于各种原因损坏,例如硬盘损坏或者传输过程中的错误而破损,那么他可能直接产生严重错误,而终止你的程序。
- lzo1x_decompress_safe
这是一个安全的解压方式,但是他会慢一些。他会捕捉解压中的数据问题,并且返回相关的错误信息,而避免产生严重错误。 - lzo1x_decompress_asm
一个类似于 lzo1x_decompress 的方式,但是是通过汇编实现的。 - lzo1x_decompress_asm_safe
一个类似于 lzo1x_decompress_safe 的方式,但是是通过汇编实现的。 - lzo1x_decompress_asm_fast
类似于 lzo1x_decompress_asm 方式,但是能够提供更快的速度。为了提高速度,他会在解压后的数据结尾添加 3 BYTE 的数据。因为这种方式按照 32 bit 作为一个单位进行数据处理。当你从一个内存块解压数据到另外一个内存块,需要多提供 3 BYTE 的数据存储空间。如果你要直接解压一个视频内容,不要使用这种方式,因为最后添加的 3 BYTE 的内容会被当成显示内容处理。
- lzo1x_decompress_asm_fast_safe
这是一个 lzo2x_decompress_asm_fast 的安全版本。
这里请注意如下内容:
- 当使用安全类型的解压方式时,要通过 dst_len 参数说明 dst 参数可以放置的数据最大容量。
- 如果你希望确认你的压缩后的数据是安全的,请使用 MD5 之类的检查,当然若使用安全类型的方式不需要这个检查。因为在安全方式中,任何错误都回被捕捉并返回。
- 汇编版本只能在 i386 的架构中使用,具体的信息可以查看 asm/i386/OOREADME.TXT 文件中查看相关内容。
- 你可能需要测试一下汇编版本是否比C语言版本速度更快,有些编译器能够完成很好的优化工作,使得C语言版本能够工作的很好。
- lzo1x_decompress
-
优化处理了哪些东西?
压缩采用了启发式方法,他们有时记录信息,这不能提高压缩比例。优化去处了这些不必要的信息,来提高解压速度。
在解压时,同样也不处理这些可能记录压缩内容变化的内容。压缩后的数据在一些 bit 中会重新排列,这不会引起压缩后数据的容量变化。
经过优化处理以后,解压速度可以提升 1-3%。优化没有更多的效果提升了。
-
我需要更快的解压速度
在很多 RISC 处理其中(例如MIPS),针对 32-bit WORD 的传送速度要快于 BYTE,这能够有效的提高解压速度。所以在验证完其他部分工作正常后,你可以在LZO1X 和LZO1Y 两种算法的解压时,采用 LZO_ALIGNED_OK_4 来提高效率。变更 config.h 中相关的内容,并且重新编译所有东西,以使用它。
在 i386 的架构中,你可以尝试使用汇编版本。
-
我如何在压缩或者解压时减少内存的使用?
如果你能够聪明的控制数据的范围,那么你可以在解压缩的时候,使用压缩使用的内存。这样能够有效的移除保存压缩后的数据的内存。这需要你了解对于可执行包裹的基础了解。
当然你也可以部分的重用压缩时的BUFF
在 examples/overlap.c 的范例中,可以看到更详细的内容。
-
我能获得一个关于预压缩的相关指导吗?
在算法 LZO1X-999 的情况下:
预压缩步骤:
1 call lzo_init() 2 call lzo1x_999_compress () 3 call lzo1x_optimze () 4 对于压缩后的数据做一个 32长度的 MD5 5 将压缩后的数据和对应的MD5保存在一个文件中 6 如果你还不放心,可以现在进行一次解压验证
解压步骤:
1 call lzo_init () 2 装载你的压缩数据和对应的 MD5 3 通过 MD5 验证你的压缩后的数据 4 解压
可以在 examples/precomp.c 和 examples/precomp2.c 的代码中查看到更详细的范例。
-
压缩以后,我的数据会增长多少?
LZO 对于不可压缩的数据,会增加一点容量。我一直没有计算过精确的数字,但是下面列出了最浪费的情况下的公式:
压缩算法:LZO1,LZO1A,LZO1B,LZO1C,LZO1F,LZO1X,LZO1Y,LZO1Z
1 output_block_size = input_block_size + (input_block_size / 16) + 64 + 3
这大约是原始数据的106%。
压缩算法:LZO2A
1 output_block_size = input_block_size + (input_block_size / 8) + 128 + 3