处理大文件的最佳 Python Zip 模块是什么？

发布于 2024-08-11 05:57:29 字数 48 浏览 2 评论 0原文

编辑：特别是压缩和提取速度。

有什么建议吗？

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

作死小能手 2024-08-18 05:57:29

因此，我制作了一个随机的大型 zip 文件：

$ ls -l *zip
-rw-r--r--  1 aleax  5000  115749854 Nov 18 19:16 large.zip
$ unzip -l large.zip | wc
   23396   93633 2254735

即 116 MB，其中有 23.4K 个文件，还有定时的东西：

$ time unzip -d /tmp large.zip >/dev/null

real    0m14.702s
user    0m2.586s
sys         0m5.408s

这是系统提供的命令行解压缩二进制文件——毫无疑问，它与纯 C 可执行文件一样经过微调和优化。是。然后（清理 /tmp;-）...：

$ time py26 -c'from zipfile import ZipFile; z=ZipFile("large.zip"); z.extractall("/tmp")'

real    0m13.274s
user    0m5.059s
sys         0m5.166s

...这是 Python 及其标准库 - 对 CPU 时间的要求更高一些，但实际上（即经过的时间）快了 10% 以上。

当然，欢迎您重复这样的测量（在您的特定平台上 - 如果它的 CPU 较差，例如缓慢的 ARM 芯片，那么 Python 对 CPU 时间的额外要求可能最终会使其变慢 - 以及您感兴趣的特定 zip 文件，因为每个大的 zip 文件将具有非常不同的组合，并且很可能具有不同的性能）。但这对我来说意味着没有足够的空间来比旧的 zipfile 更快地构建 Python 扩展 - 因为使用它的 Python 击败了纯 C、系统包含的解压缩！ -)

So I made a random-ish large zipfile:

$ ls -l *zip
-rw-r--r--  1 aleax  5000  115749854 Nov 18 19:16 large.zip
$ unzip -l large.zip | wc
   23396   93633 2254735

i.e., 116 MB with 23.4K files in it, and timed things:

$ time unzip -d /tmp large.zip >/dev/null

real    0m14.702s
user    0m2.586s
sys         0m5.408s

this is the system-supplied commandline unzip binary -- no doubt as finely-tuned and optimized as a pure C executable can be. Then (after cleaning up /tmp;-)...:

$ time py26 -c'from zipfile import ZipFile; z=ZipFile("large.zip"); z.extractall("/tmp")'

real    0m13.274s
user    0m5.059s
sys         0m5.166s

...and this is Python with its standard library - a bit more demanding of CPU time, but over 10% faster in real, that is, elapsed time.

You're welcome to repeat such measurements of course (on your specific platform -- if it's CPU-poor, e.g a slow ARM chip, then Python's extra demands of CPU time may end up making it slower -- and your specific zipfiles of interest, since each large zipfile will have a very different mix and quite possibly performance). But what this suggests to me is that there isn't that much space to build a Python extension much faster than good old zipfile -- since Python using it beats the pure-C, system-included unzip!-)

回复收藏 0 原文