java.util.zip speedup

[Artur Biesiadowski]

I have taken java version of java.util.zip from CVS and done few 
optimalizations.

I have zipped entire classpath CVS tree (5MB packed). My test program 
goes through all entries and uncompress each to memory array (same every 
time, preallocated). I have tested validity of changed by adding write 
function to recreate all files - it works ok (after fixing one existing 
bug - current version in CVS has problems with unpacking files with 0 
length).

I have measured time taken for processing using java3d high res timer, 
counting only part from opening to closing zip file - no pre and post 
computation, no jvm startup. I have started program many many times, to 
make sure everything is in memory cache. I have measured both first and 
average of 9 next iterations, but percentage speedup is similar. I have 
used sun jre 1.4.1 for testing.

Classpath CVS version needs 3150ms. My optimized version manages to do 
it in 2125ms (results vary +-3ms in each case). I think this is quite 
reasonable speedup. But real fun comes with memory. Classpath CVS 
allocates around 130MB of garbage during processing, my version  fits in 
 1MB (most of it being zip entries/names). I suppose that most of time 
difference comes from less gc work (but I have also made few 
optimalizations for reading entries from disk).

I'm quite shocked to see how fast sun gc is - even if all difference 
comes from memory, we are talking about allocating and collecting 130MB 
in 1 second - this IS a lot. I suppose that with bigger/more complicated 
heap, gc time, and thus difference, would increase considerably. Anyway, 
on less advanced jvms, difference in amount of garbage should make 
greater impact[1].

Now, the ugly part. Few of optimalizations (algorithm and IO-related) 
are free. But biggest part (memory savings) require some caching. This 
means that around 35kb is allocated first time zip subsystem is used and 
will never get freed. There is also a need for quite close look at 
inflater sharing versus security.

My question - is 35kb of memory taken 'forever' an acceptable price for 
a lot less garbage on runtime ?

Artur

[1] - On sun jvm with interpreter, difference is still around 1 second - 
but this time between 26s with classpath CVS versus 25s with my 
version... most time here is probably spend in actual decoding