This is the mail archive of the
java-discuss@sources.redhat.com
mailing list for the Java project.
Re: JVM Usenix paper got rejected
Jeff Sturm wrote:
> IIRC the real slowdown was in reading compressed jar files. If I
> extracted classes.zip or rearchived it without compression, class
> loading was significantly faster.
Hmm. I don't know what would cause that. The zip implementation itself seems to
perform ok. With the attached test case and a 750k compressed zip containing lots of
small files:
gcj 2.97 20001217:
$ ./tz sup1-egs.zip
[...]
Read 1392 entries in 522ms.
"J2RE 1.3.0 IBM build cx130-20000623":
$ java TestZip sup1-egs.zip
[...]
Read 1392 entries in 947ms.
This is despite all our Inflater methods being synchronized, which is specified in
older specs but not mentioned in the more recent javadocs etc. Anyone else think that
synchronization of the Inflater is a bit useless?
regards
[ bryce ]
import java.util.zip.*;
import java.io.*;
import java.util.*;
public class TestZip
{
static byte[] buffer;
public static void main(String[] args) throws ZipException, IOException
{
if (args.length < 1)
{
System.err.println ("Usage: testzip zipfile.zip");
System.exit(1);
}
long start = System.currentTimeMillis();
File zipfile = new File(args[0]);
ZipFile zf = new ZipFile(zipfile);
Enumeration e = zf.entries();
int count = 0;
while (e.hasMoreElements())
{
count++;
ZipEntry entry = (ZipEntry) e.nextElement();
InputStream is = zf.getInputStream(entry);
System.out.println (entry + "[" + entry.getSize() + "]");
buffer = new byte[(int) entry.getSize() + 1];
String line;
int len, pos = 0;
while ((len = is.read(buffer, pos, buffer.length - pos)) != -1)
{
pos += len;
}
if (pos != entry.getSize())
{
System.out.println ("We have a problem.");
System.exit(1);
}
}
long time = System.currentTimeMillis() - start;
System.out.println ("Read " + count + " entries in " + time + "ms.");
}
}