Is there no compression support for large sized strings in Python?

[Claudio Grondi]

What started as a simple test if it is better to load uncompressed data
directly from the harddisk or
load compressed data and uncompress it (Windows XP SP 2, Pentium4 3.0 GHz
system with 3 GByte RAM)
seems to show that none of the in Python available compression libraries
really works for large sized
(i.e. 500 MByte) strings.

Test the provided code and see yourself.

At least on my system:
zlib fails to decompress raising a memory error
pylzma fails to decompress running endlessly consuming 99% of CPU time
bz2 fails to compress running endlessly consuming 99% of CPU time

The same works with a 10 MByte string without any problem.

So what? Is there no compression support for large sized strings in Python?
Am I doing something the wrong way here?
Is there any and if yes, what is the theoretical upper limit of string size
which can be processed by each of the compression libraries?

The only limit I know about is 2 GByte for the python.exe process itself,
but this seems not to be the actual problem in this case.
There are also some other strange effects when trying to create large
strings using following code:
m = 'm'*1048576
# str1024MB = 1024*m # fails with memory error, but:
str512MB_01 = 512*m # works ok
# str512MB_02 = 512*m # fails with memory error, but:
str256MB_01 = 256*m # works ok
str256MB_02 = 256*m # works ok
etc. . etc. and so on
down to allocation of each single MB in separate string to push python.exe
to the experienced upper limit
of memory reported by Windows task manager available to python.exe of
2.065.352 KByte.
Is the question why did the str1024MB = 1024*m instruction fail,
when the memory is apparently there and the target size of 1 GByte can be
achieved
out of the scope of this discussion thread, or is this the same problem
causing
the compression libraries to fail? Why is no memory error raised then?

Any hints towards understanding what is going on and why and/or towards a
workaround are welcome.

Claudio

=============== =============== =============== ===============
# HDvsArchiveUnpa ckingSpeed_Writ eFiles.py

strSize10MB = '1234567890'*10 48576 # 10 MB
strSize500MB = 50*strSize10MB
fObj = file(r'c:\strSi ze500MB.dat', 'wb')
fObj.write(strS ize500MB)
fObj.close()

fObj = file(r'c:\strSi ze500MBCompress ed.zlib', 'wb')
import zlib
strSize500MBCom pressed = zlib.compress(s trSize500MB)
fObj.write(strS ize500MBCompres sed)
fObj.close()

fObj = file(r'c:\strSi ze500MBCompress ed.pylzma', 'wb')
import pylzma
strSize500MBCom pressed = pylzma.compress (strSize500MB)
fObj.write(strS ize500MBCompres sed)
fObj.close()

fObj = file(r'c:\strSi ze500MBCompress ed.bz2', 'wb')
import bz2
strSize500MBCom pressed = bz2.compress(st rSize500MB)
fObj.write(strS ize500MBCompres sed)
fObj.close()

print
print ' Created files: '
print ' %s \n %s \n %s \n %s' %(
r'c:\strSize500 MB.dat'
,r'c:\strSize50 0MBCompressed.z lib'
,r'c:\strSize50 0MBCompressed.p ylzma'
,r'c:\strSize50 0MBCompressed.b z2'
)

raw_input(' EXIT with Enter /> ')

=============== =============== =============== ===============
# HDvsArchiveUnpa ckingSpeed_Test Speed.py
import time

startTime = time.clock()
fObj = file(r'c:\strSi ze500MB.dat', 'rb')
strSize500MB = fObj.read()
fObj.close()
print
print ' loading uncompressed data from file: %7.3f
seconds'%(time. clock()-startTime,)

startTime = time.clock()
fObj = file(r'c:\strSi ze500MBCompress ed.zlib', 'rb')
strSize500MBCom pressed = fObj.read()
fObj.close()
print
print 'loading compressed data from file: %7.3f
seconds'%(time. clock()-startTime,)
import zlib
try:
startTime = time.clock()
strSize500MB = zlib.decompress (strSize500MBCo mpressed)
print 'decompressing zlib data: %7.3f
seconds'%(time. clock()-startTime,)
except:
print 'decompressing zlib data FAILED'
startTime = time.clock()
fObj = file(r'c:\strSi ze500MBCompress ed.pylzma', 'rb')
strSize500MBCom pressed = fObj.read()
fObj.close()
print
print 'loading compressed data from file: %7.3f
seconds'%(time. clock()-startTime,)
import pylzma
try:
startTime = time.clock()
strSize500MB = pylzma.decompre ss(strSize500MB Compressed)
print 'decompressing pylzma data: %7.3f
seconds'%(time. clock()-startTime,)
except:
print 'decompressing pylzma data FAILED'
startTime = time.clock()
fObj = file(r'c:\strSi ze500MBCompress ed.bz2', 'rb')
strSize500MBCom pressed = fObj.read()
fObj.close()
print
print 'loading compressed data from file: %7.3f
seconds'%(time. clock()-startTime,)
import bz2
try:
startTime = time.clock()
strSize500MB = bz2.decompress( strSize500MBCom pressed)
print 'decompressing bz2 data: %7.3f
seconds'%(time. clock()-startTime,)
except:
print 'decompressing bz2 data FAILED'

raw_input(' EXIT with Enter /> ')

[Fredrik Lundh]

Claudio Grondi wrote:

What started as a simple test if it is better to load uncompressed data
directly from the harddisk or
load compressed data and uncompress it (Windows XP SP 2, Pentium4 3.0 GHz
system with 3 GByte RAM)
seems to show that none of the in Python available compression libraries
really works for large sized
(i.e. 500 MByte) strings.

Test the provided code and see yourself.

At least on my system:
zlib fails to decompress raising a memory error
pylzma fails to decompress running endlessly consuming 99% of CPU time
bz2 fails to compress running endlessly consuming 99% of CPU time

The same works with a 10 MByte string without any problem.

So what? Is there no compression support for large sized strings in Python?

you're probably measuring windows' memory managment rather than the com-
pression libraries themselves (Python delegates all memory allocations >256 bytes
to the system).

I suggest using incremental (streaming) processing instead; from what I can tell,
all three libraries support that.

</F>

[jepler]

On this system (Linux 2.6.x, AMD64, 2 GB RAM, python2.4) I am able to
construct a 1 GB string by repetition, as well as compress a 512MB
string with gzip in one gulp.

$ cat claudio.py
s = '1234567890'*(1 048576*50)

import zlib
c = zlib.compress(s )
print len(c)
open("/tmp/claudio.gz", "wb").write (c)

$ python claudio.py
1017769

$ python -c 'print len("m" * (1048576*1024)) '
1073741824

I was also able to create a 1GB string on a different system (Linux 2.4.x,
32-bit Dual Intel Xeon, 8GB RAM, python 2.2).

$ python -c 'print len("m" * 1024*1024*1024) '
1073741824

I agree with another poster that you may be hitting Windows limitations rather
than Python ones, but I am certainly not familiar with the details of Windows
memory allocation.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDjvx7Jd0 1MZaTXX0RAo7HAK CEhtbvyS3GSfJPs qq0W5R5EOLgTwCf Vb7o
OSlY79Rl7HCLLNQ Q4axI6AA=
=qTA2
-----END PGP SIGNATURE-----

[Claudio Grondi]

"Fredrik Lundh" <fr*****@python ware.com> schrieb im Newsbeitrag
news:ma******** *************** *************** *@python.org...

Claudio Grondi wrote:

What started as a simple test if it is better to load uncompressed data
directly from the harddisk or
load compressed data and uncompress it (Windows XP SP 2, Pentium4 3.0 GHz system with 3 GByte RAM)
seems to show that none of the in Python available compression libraries
really works for large sized
(i.e. 500 MByte) strings.

Test the provided code and see yourself.

At least on my system:
zlib fails to decompress raising a memory error
pylzma fails to decompress running endlessly consuming 99% of CPU time
bz2 fails to compress running endlessly consuming 99% of CPU time

The same works with a 10 MByte string without any problem.

So what? Is there no compression support for large sized strings in

Python?
you're probably measuring windows' memory managment rather than the com-
pression libraries themselves (Python delegates all memory allocations
256 bytes
to the system).

I suggest using incremental (streaming) processing instead; from what I can tell, all three libraries support that.

</F>

Have solved the problem with bz2 compression the way Frederic suggested:

fObj = file(r'd:\strSi ze500MBCompress ed.bz2', 'wb')
import bz2
objBZ2Compresso r = bz2.BZ2Compress or()
lstCompressBz2 = []
for indx in range(0, len(strSize500M B), 1048576):
lowerIndx = indx
upperIndx = indx+1048576
if(upperIndx > len(strSize500M B)): upperIndx = len(strSize500M B)

lstCompressBz2. append(objBZ2Co mpressor.compre ss(strSize500MB[lowerIndx:upper
Indx]))
#:for
lstCompressBz2. append(objBZ2Co mpressor.flush( ))
strSize500MBCom pressed = ''.join(lstComp ressBz2)
fObj.write(strS ize500MBCompres sed)
fObj.close()

:-)

so I suppose, that the decompression problems can also be solved that way,
but :

This still doesn't for me answer the question what the core of the problem
was, how to avoid it and what are the memory request limits which should be
considered when working with large strings?
Is it actually so, that on other systems than Windows 2000/XP there is no
problem with the original code I have provided?
Maybe a good reason to go for Linux instead of Windows? Does e.g. Suse or
Mandriva Linux have also a memory limit a single Python process can use?
Please let me know about your experience.

Claudio

[Gerald Klix]

Did you consider the mmap library?
Perhaps it is possible to avoid to hold these big stings in memory.
BTW: AFAIK it is not possible in 32bit windows for an ordinary programm
to allocate more than 2 GB. That restriction comes from the jurrasic
MIPS-Processors, that reserved the upper 2 GB for the OS.

HTH,
Gerald

Claudio Grondi schrieb:

"Fredrik Lundh" <fr*****@python ware.com> schrieb im Newsbeitrag
news:ma******** *************** *************** *@python.org...

Claudio Grondi wrote:

What started as a simple test if it is better to load uncompressed data
directly from the harddisk or
load compressed data and uncompress it (Windows XP SP 2, Pentium4 3.0
GHz
system with 3 GByte RAM)
seems to show that none of the in Python available compression libraries
really works for large sized
(i.e. 500 MByte) strings.

Test the provided code and see yourself.

At least on my system:
zlib fails to decompress raising a memory error
pylzma fails to decompress running endlessly consuming 99% of CPU time
bz2 fails to compress running endlessly consuming 99% of CPU time

The same works with a 10 MByte string without any problem.

So what? Is there no compression support for large sized strings in

Python?

you're probably measuring windows' memory managment rather than the com-
pression libraries themselves (Python delegates all memory allocations
256 bytes
to the system).

I suggest using incremental (streaming) processing instead; from what I

can tell,

all three libraries support that.

</F>

Have solved the problem with bz2 compression the way Frederic suggested:

fObj = file(r'd:\strSi ze500MBCompress ed.bz2', 'wb')
import bz2
objBZ2Compresso r = bz2.BZ2Compress or()
lstCompressBz2 = []
for indx in range(0, len(strSize500M B), 1048576):
lowerIndx = indx
upperIndx = indx+1048576
if(upperIndx > len(strSize500M B)): upperIndx = len(strSize500M B)

lstCompressBz2. append(objBZ2Co mpressor.compre ss(strSize500MB[lowerIndx:upper
Indx]))
#:for
lstCompressBz2. append(objBZ2Co mpressor.flush( ))
strSize500MBCom pressed = ''.join(lstComp ressBz2)
fObj.write(strS ize500MBCompres sed)
fObj.close()

:-)

so I suppose, that the decompression problems can also be solved that way,
but :

This still doesn't for me answer the question what the core of the problem
was, how to avoid it and what are the memory request limits which should be
considered when working with large strings?
Is it actually so, that on other systems than Windows 2000/XP there is no
problem with the original code I have provided?
Maybe a good reason to go for Linux instead of Windows? Does e.g. Suse or
Mandriva Linux have also a memory limit a single Python process can use?
Please let me know about your experience.

Claudio

[Christophe]

Gerald Klix a écrit :

Did you consider the mmap library?
Perhaps it is possible to avoid to hold these big stings in memory.
BTW: AFAIK it is not possible in 32bit windows for an ordinary programm
to allocate more than 2 GB. That restriction comes from the jurrasic
MIPS-Processors, that reserved the upper 2 GB for the OS.

As a matter of fact, it's Windows which reserved the upper 2 GB. There a
simple setting to change that value so that you have 3 GB available and
another setting which can even go as far as 3.5 GB available per process.

[Fredrik Lundh]

Christophe wrote:

Did you consider the mmap library?
Perhaps it is possible to avoid to hold these big stings in memory.
BTW: AFAIK it is not possible in 32bit windows for an ordinary programm
to allocate more than 2 GB. That restriction comes from the jurrasic
MIPS-Processors, that reserved the upper 2 GB for the OS.

As a matter of fact, it's Windows which reserved the upper 2 GB. There a
simple setting to change that value so that you have 3 GB available and
another setting which can even go as far as 3.5 GB available per process.

random raymond chen link:

http://blogs.msdn.com/oldnewthing/ar...05/208908.aspx

</F>

[Claudio Grondi]

I was also able to create a 1GB string on a different system (Linux 2.4.x,
32-bit Dual Intel Xeon, 8GB RAM, python 2.2).
$ python -c 'print len("m" * 1024*1024*1024) '
1073741824
I agree with another poster that you may be hitting Windows limitations
rather
than Python ones, but I am certainly not familiar with the details of
Windows
memory allocation.
Jeff
----------

Here my experience with hunting after the memory limit exactly the way Jeff
did it (Windows 2000, Intel Pentium4, 3GB RAM, Python 2.4.2):

\>python -c "print len('m' * 1024*1024*1024) "
1073741824

\>python -c "print len('m' * 1136*1024*1024) "
1191182336

\>python -c "print len('m' * 1236*1024*1024) "
Traceback (most recent call last):
File "<string>", line 1, in ?
MemoryError

Anyone on a big Linux machine able to do e.g. :
\>python -c "print len('m' * 2500*1024*1024) "
or even more without a memory error?

I suppose, that on the Dual Intel Xeon, even with 8 GByte RAM the upper
limit for available memory will be not larger than 4 GByte.
Can someone point me to an Intel compatible PC which is able to provide more
than 4 GByte RAM to Python?

Claudio

[Harald Karner]

Claudio Grondi wrote:

Anyone on a big Linux machine able to do e.g. :
\>python -c "print len('m' * 2500*1024*1024) "
or even more without a memory error?
I tried on a Sun with 16GB Ram (Python 2.3.2)
seems like 2GB is the limit for string size:
python -c "print len('m' * 2048*1024*1024) " Traceback (most recent call last):
File "<string>", line 1, in ?
OverflowError: repeated string is too long
python -c "print len('m' * ((2048*1024*102 4)-1))"

2147483647

[Fredrik Lundh]

Harald Karner wrote:

I tried on a Sun with 16GB Ram (Python 2.3.2)
seems like 2GB is the limit for string size:

python -c "print len('m' * 2048*1024*1024) "

Traceback (most recent call last):
File "<string>", line 1, in ?
OverflowError: repeated string is too long

python -c "print len('m' * ((2048*1024*102 4)-1))"

2147483647

the string type uses the ob_size field to hold the string length, and
ob_size is an integer:

$ more Include/object.h
...
int ob_size; /* Number of items in variable part */
...

anyone out there with an ILP64 system?

</F>