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



_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath