Andre Berg andre.b...@email.de added the comment:
If I may chime in, as I don't know where else to put this.
I am still seeing the same performance as the OP when I use extractall() with a
password protected ZIP of size 287 MB (containing one compressed movie file of
size 297 MB).
The total
Antoine Pitrou pit...@free.fr added the comment:
I am still seeing the same performance as the OP when I use
extractall() with a password protected ZIP of size 287 MB (containing
one compressed movie file of size 297 MB).
Please try with a non-password protected file.
--
Andre Berg andre.b...@email.de added the comment:
Decryption is extremely slow as it is implemented in native Python rather than
C
Right, of course, I missed this when reading the docs.
I have a habit of jumping straight to the point.
As I was asked to try it with a non-password protected zip
Antoine Pitrou pit...@free.fr added the comment:
The patch has been outdated by other independent performance work on the
zipfile module. In Python 3.2, the zipfile module is actually slightly faster
than the unzip program:
- first with the supplied zeroes.zip file:
$ rm -f zeroes time -p
Antoine Pitrou pit...@free.fr added the comment:
Attaching a cleanup of the proposed patch. The funny thing is that for
me, both the unpatched and patched versions are as fast as the unzip binary.
Added file: http://bugs.python.org/file12346/zipperf.patch
Changes by James Athey [EMAIL PROTECTED]:
--
title: ZipFileExt.read() can be incredibly slow - ZipFileExt.read() can be
incredibly slow; patch included
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3978
