Re: ZipInputStream brokenness

[Jeff Sturm <jsturm at one-point dot com>]

On Sat, 31 Aug 2002, Jesse Rosenstock wrote:
> Adam> I suggested merging the classpath implementation:
> Adam>     http://gcc.gnu.org/ml/java/2002-06/msg00023.html
>
> I would vote for that, too (not that I get a vote).  Does anyone have
> specific performance, correctness, memory usage, coding style or other
> objections?

There is a performance problem in both java.util.zip implementations:
unbuffered I/O.  Running the small test case:

import java.io.*;
import java.net.*;

public class J {
  public static void main(String[] args) {
    try {
      URL url = new
URL("jar:file:/opt/gcc/share/java/libgcj-3.3.jar!/java/lang/Object.class");
      InputStream is = url.openStream();
      byte[] buf = new byte[8192];
      is.read(buf);
    } catch (IOException ex) {
      ex.printStackTrace();
    }
  }
}

under strace, I get:

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 87.28    0.612733           9     65811           read
  7.18    0.050436           4     11976           lseek
  3.15    0.022138           5      4036           fstat

At least 2/3 of runtime is system call overhead.  And this is on Linux.
It's far more noticeable on platforms with expensive syscalls (Solaris).

I don't see this penalty running an equivalent extract with e.g. fastjar.

I have no opinion w.r.t. correctness, though I haven't tested the
classpath code much.  In particular I haven't been bitten by Adam's
problem yet, nor have I tried his testcase.

Speaking for myself, I don't see a win from merging the classpath code.
I'd rather spend time fixing the I/O.

Jeff