Antoine Pitrou <pit...@free.fr> added the comment: > >> Modules/_lzmamodule.c:115: return _PyBytes_Resize(buf, size + BIGCHUNK); > > This has quadratic performance. > > Correct. I copied the algorithm from _io.FileIO, under the assumption > that there was a reason for not using a simpler O(n log n) doubling > strategy. Do you know of any reason for this? Or is it safe to ignore it?
I don't know, but I'd say it's safe to ignore it. Maybe open a separate bug about that. Generally we use a less-than-doubling strategy, to conserve memory (see e.g. bytearray.c). (note: it is O(n), not O(n log n)) > >> Modules/_lzmamodule.c:364: Py_BEGIN_ALLOW_THREADS > > It seems that the Windows version at least is not thread-safe. If so, you > > would need an LZMA lock when releasing the GIL. > > Does the class need to be thread-safe, though? ISTM that there isn't any > sensible use case for having two threads feeding data through the same > compressor concurrently. We certainly want to avoid crashes so, if that's what one risks from using lzma from several threads, we should protect against it. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue6715> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
