asnakelover <a3277...@uggsrock.com> added the comment: The gz in question is 17mb compressed and 247mb uncompressed. Calling zcat the python process uses between 250 and 260 mb with the whole string in memory using zcat as a fork. Numbers for the gzip module aren't obtainable except for readline(), which doesn't use much memory but is very slow. Other methods thrash the machine to death.
The machine has 300mb free RAM from a total of 1024mb. It's not a new issue, I didn't find it when searching python bug archives for some reason but google: http://www.google.com/search?q=python+gzip+slow+zcat It's an issue which people have stumbled into before but nobody seems to have made headway any headway (I expect they just forked and called zcat or gzip, like I did...). It's a minor point since it's so easy to work around, in fact I have my IDS system completed already - thank you so much python for being so RAD friendly - yet the module is worthless if a user has zcat/gzip c programs and knows they exist as it stands. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7471> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
