Python解压相对性能？

2023-11-22

太长了；的python 中可用的各种压缩算法 gzip, bz2, lzma等，哪个有最好的减压表现？

完整讨论：

Python 3 有用于压缩/解压缩数据的各种模块包括gzip, bz2 and lzma. gzip and bz2此外，您还可以设置不同的压缩级别。

如果我的目标是平衡文件大小（/压缩比）和解压缩速度（压缩速度不是问题），那么哪个将是最佳选择？解压速度比文件大小更重要，但由于所讨论的未压缩文件每个约为 600-800MB（32 位 RGB .png 图像文件），而且我有十几个，我确实想要some压缩。

我的用例是，我从磁盘加载十几个图像，对它们进行一些处理（作为 numpy 数组），然后在我的程序中使用处理后的数组数据。
- 图像永远不会改变，我只需要在每次运行程序时加载它们。
- 处理所需的时间与加载时间大致相同（几秒），因此我尝试通过保存处理后的数据来节省一些加载时间（使用pickle）而不是每次都加载原始的、未处理的图像。最初的测试很有希望 - 加载原始/未压缩的 pickled 数据花费了不到一秒的时间，而加载和处理原始图像则需要 3 或 4 秒 - 但正如前面提到的，文件大小约为 600-800MB，而原始 png 图像是仅5MB左右。因此，我希望可以通过以压缩格式存储选取的数据来在加载时间和文件大小之间取得平衡。
更新：情况实际上比我上面描述的要复杂一些。我的应用程序使用PySide2，所以我可以访问Qt图书馆。
- 如果我读取图像并使用转换为 numpy 数组pillow (PIL.Image），实际上我不需要做任何处理，但是将图像读入数组的总时间约为 4 秒。
- 如果我使用QImage要读取图像，我必须对结果进行一些处理，以使其可用于我的程序的其余部分，因为它的字节顺序QImage加载数据 - 基本上我必须交换位顺序，然后旋转每个“像素”，以便 alpha 通道（显然是由 QImage 添加的）出现在最后而不是第一个。整个过程大约需要3.8秒，所以边际地比仅仅使用 PIL 更快。
- 如果我保存numpy数组未压缩，然后我可以在 0.8 秒内将它们加载回来，因此是迄今为止最快的，但文件大小很大。

┌────────────┬────────────────────────┬───────────────┬─────────────┐
│ Python Ver │     Library/Method     │ Read/unpack + │ Compression │
│            │                        │ Decompress (s)│    Ratio    │
├────────────┼────────────────────────┼───────────────┼─────────────┤
│ 3.7.2      │ pillow (PIL.Image)     │ 4.0           │ ~0.006      │
│ 3.7.2      │ Qt (QImage)            │ 3.8           │ ~0.006      │
│ 3.7.2      │ numpy (uncompressed)   │ 0.8           │ 1.0         │
│ 3.7.2      │ gzip (compresslevel=9) │ ?             │ ?           │
│ 3.7.2      │ gzip (compresslevel=?) │ ?             │ ?           │
│ 3.7.2      │ bz2 (compresslevel=9)  │ ?             │ ?           │
│ 3.7.2      │ bz2 (compresslevel=?)  │ ?             │ ?           │
│ 3.7.2      │ lzma                   │ ?             │ ?           │
├────────────┼────────────────────────┼───────────────┼─────────────┤
│ 3.7.3      │ ?                      │ ?             │ ?           │  
├────────────┼────────────────────────┼───────────────┼─────────────┤
│ 3.8beta1   │ ?                      │ ?             │ ?           │
├────────────┼────────────────────────┼───────────────┼─────────────┤
│ 3.8.0final │ ?                      │ ?             │ ?           │
├────────────┼────────────────────────┼───────────────┼─────────────┤
│ 3.5.7      │ ?                      │ ?             │ ?           │
├────────────┼────────────────────────┼───────────────┼─────────────┤
│ 3.6.10     │ ?                      │ ?             │ ?           │
└────────────┴────────────────────────┴───────────────┴─────────────┘

示例 .png 图像：举个例子，以这个 5.0Mb png 图像，阿拉斯加海岸线的相当高分辨率的图像.

png/PIL 案例的代码（加载到numpy array):

from PIL import Image
import time
import numpy

start = time.time()
FILE = '/path/to/file/AlaskaCoast.png'
Image.MAX_IMAGE_PIXELS = None
img = Image.open(FILE)
arr = numpy.array(img)
print("Loaded in", time.time()-start)

在我使用 Python 3.7.2 的机器上，此负载大约需要 4.2 秒。

或者，我可以加载通过选择上面创建的数组生成的未压缩的 pickle 文件。

未压缩pickle负载情况的代码：

import pickle
import time

start = time.time()    
with open('/tmp/test_file.pickle','rb') as picklefile:
  arr = pickle.load(picklefile)    
print("Loaded in", time.time()-start)

在我的机器上，从这个未压缩的 pickle 文件加载大约需要 0.8 秒。

唾手可得的果实

numpy.savez_compressed('AlaskaCoast.npz', arr)
arr = numpy.load('AlaskaCoast.npz')['arr_0']

加载速度比基于 OIL 的代码快 2.3 倍。

It uses zipfile.ZIP_DEFLATED, see 保存压缩 docu.

您的 PIL 代码还有一个不需要的副本：array(img)应该asarray(img)。仅花费5%的慢加载时间。但优化后这将很重要，你必须记住哪些 numpy 运算符创建了副本。

快速减压

根据zstd 基准测试，当优化减压时lz4是一个不错的选择。只需将其插入 pickle 即可获得 2.4 倍的增益，并且仅比未压缩的 pickle 慢 30%。

import pickle
import lz4.frame

# with lz4.frame.open('AlaskaCoast.lz4', 'wb') as f:
#     pickle.dump(arr, f)

with lz4.frame.open('AlaskaCoast.lz4', 'rb') as f:
    arr = pickle.load(f)

基准测试

method                 size   load time
------                 ----   ---------
original (PNG+PIL)     5.1M   7.1
np.load (compressed)   6.7M   3.1
pickle + lz4           7.1M   1.3
pickle (uncompressed)  601M   1.0 (baseline)

加载时间是在 Python (3.7.3) 内测量的，使用的是在我的桌面上运行 20 多次的最小挂钟时间。根据偶尔的扫视top它似乎总是在单核上运行。

对于好奇的人：分析

我不确定 Python 版本是否重要，大多数工作应该在 C 库内部进行。为了验证这一点，我已经分析了pickle + lz4变体：

perf record ./test.py && perf report -s dso
Overhead  Shared Object
  60.16%  [kernel.kallsyms]  # mostly page_fault and alloc_pages_vma
  27.53%  libc-2.28.so       # mainly memmove
   9.75%  liblz4.so.1.8.3    # only LZ4_decompress_*
   2.33%  python3.7
   ...

大部分时间都花在 Linux 内核内部，page_fault以及与（重新）分配内存相关的内容，可能包括磁盘 I/O。金额高memmove看起来很可疑。每次新的解压块到达时，Python 可能都会重新分配（调整大小）最终数组。如果有人想仔细看看：python 和 perf 配置文件.

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)