In order to test the performance of linux compression utilities, I compressed and decompressed a 336MB directory. Here are the results.
| Compression |
| Version | Command | Time | Size (in MB) |
| 1.4.1_01 | jar cf | 14m41.860s | 206 |
| 0.93 | fastjar cf | 4m7.200s | 206 |
| 2.3-12 | zip -rq | 3m43.058s | 206 |
| 1.3.19 | tar cf | 0m42.199s | 315 |
| 1.3.19 | tar czf (gzip) | 3m34.422s | 162 |
| 1.3.19 | tar cjf (bzip) | 8m11.907s | 153 |
| Decompression |
| Version | Command | Time |
| 1.4.1_01 | jar xf | 2m2.162s |
| 0.93 | fastjar xf | 1m16.303s |
| 5.50 | unzip -qq | 1m10.796s |
| 1.3.19 | tar xf | 1m20.216s |
| 1.3.19 | tar xzf (gzip) | 1m6.717s |
| 1.3.19 | tar xjf (bzip) | 3m15.317s |
I remember watching you perform this exercise a while back. What I didn’t know, is that [jar] is basically just zip. Since .jar file are passed over the network so often I wonder why they didn’t go for something a bit tighter and faster. Would it interfere with how java pulls classes from the jar file?
One reason is that there is not a standard tar (that I know of) on Mac and Windows, while zip is more universal. The only difference between jar files and zip files are that jar adds a manifest.
hello sir,
i want to know whether there is any data lose during the compression and decompression? is it everytime safe to do in regards of data lose?
Dushyant: There is no data loss. They would be pretty useless utilities if you lost your data in the process.