已知Python的gzip.writer是慢的吗？

Question

我为我的雇主写了一个处理CSV文件的脚本。处理是CPU绑定的，文件很大.例如，输入的3+ GB产生6+ GB的输出。

在我的机器上，这个文本文件的转换几乎需要16分钟(这本身就有点长，但我使用的是股票csv-module)，其中大约30秒是由操作系统(编写输出)花费的。

对于kick，我添加了一个透明压缩功能：

if name.endswith('.gz'):
    import gzip
    return gzip.GzipFile(name, mode, 9, fd)
return fd

当使用压缩时，运行时跳到超过一个小时--尽管sys时减半，因为需要编写的时间要少得多。

跳转是可以理解的，但是它的规模不是--如果我只是在未压缩的输出文件上运行gzip -9，它只需要13分钟。

我可以理解，gzip可能会通过使用更大的缓冲区等来赢得一些东西--但是在我的脚本中嵌入压缩应该能够从更少的数据复制中受益。然而，它失去了比2:1: 16分钟的转换时间+ 13分钟的压缩时间和61分钟的时间来完成这两项任务。

为何会有这么大的差距呢？众所周知，Python-2.x中的zlib/gzip代码很慢吗？如果Python-3在这方面做得更好--在未压缩的处理中更糟糕.

Answer 1

我的一位同事注意到Python的gzip和bash的gzip之间的默认压缩级别是不同的。

默认情况下，Python实现使用9(最慢)的压缩级别。

gzip.open(filename, mode='rb', compresslevel=9, encoding=None, errors=None, newline=None)

默认情况下，bash gzip命令使用6级：

默认的压缩级别是-6 (也就是说，倾向于以牺牲速度为代价的高压缩)。