Skip to main content

Bad performance with java.util.zip.Deflater after jdk1.5.0_06 and jdk 6

5 replies [Last post]
starm
Offline
Joined: 2007-12-20
Points: 0

Hello,

I have a problem with the jdk 5 and 6. After the version 1.5.0_06, the classe java.util.zip.Deflater and Inflater have very bad performance. With the version 1.5.0_06, there is no pb, to compress a strem of 50Mo, he needs 1,5 sec instead of the version 1.5.0_07 and all others after, he needs 60 sec...

Is there anybody who have the same pb ?

(Sorry for the bad english ... )

I use this code :

public static byte[] compresserZlib(byte[] donnees)
{
ByteArrayOutputStream resultat = new ByteArrayOutputStream();
byte[] buffer = new byte[1000];
int nbEcrits;

Deflater deflater = new Deflater();
deflater.setInput(donnees);
deflater.setLevel(9);
deflater.finish();

while (!deflater.finished())
{
nbEcrits = deflater.deflate(buffer);
resultat.write(buffer, 0, nbEcrits);
}

return resultat.toByteArray();
}

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
linuxhippy
Offline
Joined: 2004-01-07
Points: 0

You're right - I tested a 5mb file which took 1s with JDK1.4.2, and 10s with 1.7.0_ea-b23.

The problem with your code is that buffers are way too small - the overhead for fetching the 100bytes is much larger than the actual time it takes to compress the data.

Try to increase the buffer-size to e.g. 32000 bytes and you'll get at least acceptable results.

lg Clemens

PS: I'll profile a bit to see where the problem lies.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

I did some further testing and indeed, its really a performance bug - the code copies over and over.

I'll try to solve it, meanwhile use a large buffer-size (~5mb) which should hide the problem a bit.

lg Clemens

starm
Offline
Joined: 2007-12-20
Points: 0

Ok, indeed it is better. With a buffer of 1mb I have a good performance.
So is it a bug of jdk or a voluntary amendment ?
Do you think I need to signal the bug on the Website of Sun ?

Thank you for your responses.

linuxhippy
Offline
Joined: 2004-01-07
Points: 0

Best would be a buffer which is as large as the expected result - so a buffer which is as large as the original data guarantees no penalty.

Sun knows about the bug, and there's a long history of changes - each change solved some problems and introduced some now problems - also the native code looks a bit hacked.
I'll try to get a fix together - just for fun - but I can't promise SUN would like it or accept the code at all, nore that I am really able to solve the problems.

lg Clemens

starm
Offline
Joined: 2007-12-20
Points: 0

Ok, thank you for your help and your support.