DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=31930>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31930 Zip & Unzip tasks major slowdown ------- Additional Comments From [EMAIL PROTECTED] 2004-11-12 23:50 ------- It looks like a major slowdown is the hashtable put/get on the ZipEntry element that seems to be due by collisions in the hashtable. The problem seems to be caused by o.a.t.z.ZipEntry incorrectly inheriting from j.u.z.ZipEntry. In ZipFile it creates all ZipEntries but the initial name when being inserted in the hashtable is always "", and this is the one being used for the instance hashcode (oups !)...and equals is not overriden in the base class too. If I override hashcode() and add a equals to ZipEntry and move the hashtable insertion down a few lines in ZipFile so that the entry is initialized with the right name, I have a nearly 3x improvement. Using j2sdk-1_4_2-doc.doc.zip (9525 entries, 35.8MB) as a zip file, I can run the attached testcase with the following timing: Client VM Time taken for JazzZipFile Read: 6239 Time taken for JavaZipFile Read: 4216 Time taken for ApacheZipFile Read: 4827 Server VM Time taken for JazzZipFile Read: 5198 Time taken for JavaZipFile Read: 4296 Time taken for ApacheZipFile Read: 5588 (JDK 1.4.2_06 on a Centrino 1.7GHz) I did a couple of small optimizations as well to avoid unecessary object creation ie new ZipShort(..).getValue() as ZipShort.getValue(...), same for ZipLong. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
