Author pitrou
Recipients Christophe Simonis, Garen, Nam.Nguyen, amaury.forgeotdarc, arekm, asvetlov, barry, doko, eric.araujo, georg.brandl, jcea, jeremybanks, lars.gustaebel, leonov, loewis, nadeem.vawda, nicdumz, nikratio, ockham-razor, pitrou, proyvind, rcoyner, shirish, strombrg, thedjatclubrock, tshepang, vstinner, ysj.ray
Date 2011-10-11.11:39:02
SpamBayes Score 9.94622e-09
Marked as misclassified No
Message-id <1318332919.3277.3.camel@localhost.localdomain>
In-reply-to <>
> >> 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.
Date User Action Args
2011-10-11 11:39:03pitrousetrecipients: + pitrou, loewis, barry, georg.brandl, doko, jcea, amaury.forgeotdarc, arekm, lars.gustaebel, vstinner, nadeem.vawda, nicdumz, eric.araujo, Christophe Simonis, rcoyner, proyvind, asvetlov, nikratio, leonov, Garen, ysj.ray, thedjatclubrock, ockham-razor, strombrg, shirish, tshepang, jeremybanks, Nam.Nguyen
2011-10-11 11:39:02pitroulinkissue6715 messages
2011-10-11 11:39:02pitroucreate