Xueming.Shen at Sun.COM
Mon May 18 14:07:33 PDT 2009
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.
of part of the code is at
Just tried to share some idea for discussion.
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