Inflater/Deflater improvements (original) (raw)

Xueming Shen Xueming.Shen at Sun.COM
Mon May 18 21:07:33 UTC 2009

Clemens,

If I read the code correctly, what your patch is trying to address is to save the redundant memory allocate/free operations at native level, if the input byte buffer is bigger than the "stride" size? In other words, it does not really reduce any memory copy but reduce the trip numbers of java<->native. Am I reading the code correctly? I will take a second round of read later...

Couple months ago I also tried some experimental code on the zip package, then I got detoured to something else:-( maybe it's the time to revisit it, together with your code.

What I was trying to do is to pull as much as the native stuff to the java level...and to use the ByteBuffer instead of byte[], in which we might get the chance to really reduce the copy of data, if the input ByteBuffer is a direct bytebuffer...there was a nasty bug somewhere in the code I did not have time to figure out back then tough. The snapshot of part of the code is at

http://cr.openjdk.java.net/~sherman/deflater2/webrev/

Just tried to share some idea for discussion.

Sherman

Clemens Eisserer wrote:

Hi Martin,

I think many people will be interested in performance improvements in Inflater/Deflater. I may have time to help review. Caution: This is an area where it can be very tricky to make improvements. Past efforts have optimized one usage pattern at the cost of pessimizing another. I can't imagine a use-case where this version would perform a lot worse, however a clear downside is for sure the larger amount of C-heap consumed. However the current implementation is so bad, it should be worth it ;) I am more afraid of behaviour change in corner cases ... Thanks, Clemens

More information about the core-libs-dev mailing list