Code Review Request for # 6975829 : Perf. of gzip in existing JDKs is too slower than in 1.3.1
Alan Bateman
Alan.Bateman at oracle.com
Wed Oct 6 13:19:06 UTC 2010
Xueming Shen wrote:
> Alan,
>
> It appears we do have a regression test [1] in our repository to make
> sure that
> we do NOT do round-trip more than necessary for "short" input. While
> the change
> in http://cr.openjdk.java.net/~sherman/6975829/webrev
> <http://cr.openjdk.java.net/%7Esherman/6975829/webrev.00/>.00
> <http://cr.openjdk.java.net/%7Esherman/6975829/webrev.00/> does not
> "break"
> anything, it does go to the inflater more than once for this corner case.
>
> I updated the webrev to add some "overhead" bytes. This "20 bytes"
> overhead
> probably will make some other corner cases less optimistic, but that
> would not
> be a regression.
>
> http://cr.openjdk.java.net/~sherman/6975829/webrev
> <http://cr.openjdk.java.net/%7Esherman/6975829/webrev/>
>
> -Sherman
>
> [1] test/java/util/ZipFile/ShortRead.java
Yep, the zip code always manages to bite whoever touches it. Is it worth
writing a few more tests to make sure that we don't have any regression
in other corner cases?
Would be better to just initialize in_len to MIN(this_len, len + 20)?
(and maybe define a constant for the size of the extra space?).
-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20101006/63cadf43/attachment.html>
More information about the core-libs-dev
mailing list