Message 217393 - Python tracker

Message217393

Author	neologix
Recipients	ezio.melotti, nadeem.vawda, neologix, pitrou, serhiy.storchaka, skip.montanaro, tiwilliam
Date	2014-04-28.18:52:27
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<CAH_1eM3Ffgt+wvpOHze6mUD7Tubz4QZBwGs5u81fp2JrZbNc3g@mail.gmail.com>
In-reply-to	<1398709321.48.0.427240583039.issue20962@psf.upfronthosting.co.za>

Content
> I don't think io.DEFAULT_BUFFER_SIZE makes much sense as a heuristic for the gzip module (or compressed files in general). Perhaps gzip should get its own DEFAULT_BUFFER_SIZE? Do you mean from a namespace point of vue, or from a performance point of view? Because this size is used to read/write from underlying the file object, so using the io default would make sense, no? Sure, it might not be optimal for compressed files, but I gues that the optimal value is function of the compression-level block size and many other factors which are just too varied to come up with a reasonable heuristic.

Content

> I don't think io.DEFAULT_BUFFER_SIZE makes much sense as a heuristic for the gzip module (or compressed files in general). Perhaps gzip should get its own DEFAULT_BUFFER_SIZE?

Do you mean from a namespace point of vue, or from a performance point of view?
Because this size is used to read/write from underlying the file
object, so using the io default would make sense, no?

Sure, it might not be optimal for compressed files, but I gues that
the optimal value is function of the compression-level block size and
many other factors which are just too varied to come up with a
reasonable heuristic.

History
Date	User	Action	Args
2014-04-28 18:52:28	neologix	set	recipients: + neologix, skip.montanaro, pitrou, nadeem.vawda, ezio.melotti, serhiy.storchaka, tiwilliam
2014-04-28 18:52:27	neologix	link	issue20962 messages
2014-04-28 18:52:27	neologix	create