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.