[issue3978] ZipFileExt.read() can be incredibly slow; patch included

Andre Berg 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 file here's the

[issue3978] ZipFileExt.read() can be incredibly slow; patch included

Antoine Pitrou 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. -- __

[issue3978] ZipFileExt.read() can be incredibly slow; patch included

Andre Berg 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 running time for ext

[issue3978] ZipFileExt.read() can be incredibly slow; patch included

Antoine Pitrou 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 unzip -e z

[issue3978] ZipFileExt.read() can be incredibly slow; patch included

Antoine Pitrou 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 ___ Python tracke

[issue3978] ZipFileExt.read() can be incredibly slow; patch included

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]> _

[issue3978] ZipFileExt.read() can be incredibly slow

James Athey <[EMAIL PROTECTED]> added the comment: Why not include this in 2.6.1 or 3.0.1? The patch fixes several bugs; it does not provide any new functionality. ___ Python tracker <[EMAIL PROTECTED]> _

[issue3978] ZipFileExt.read() can be incredibly slow

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Very interesting, but it will have to wait for 2.7/3.1. 2.6 and 3.0 are in the final phases of the release process. -- nosy: +pitrou priority: -> normal versions: +Python 3.1 -Python 2.6 ___ Pytho

[issue3978] ZipFileExt.read() can be incredibly slow

Changes by James Athey <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11622/zeroes.zip ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3978] ZipFileExt.read() can be incredibly slow

New submission from James Athey <[EMAIL PROTECTED]>: I've created a patch that improves the decompression performance of zipfile.py by up to two orders of magnitude. In ZipFileExt.read(), decompressed bytes waiting to be read() sit in a string buffer, self.readbuffer. When a piece of that strin