Rzip compression tests
In the wake of yesterday's post about transferring large volumes of files, I decided to see how well rzip would fare when compressing a directory holding a built version of ffmpeg, compared to an unbuilt version.
| Size | Filename | Ratio |
|---|---|---|
| 67M | ffmpeg | 1.0 |
| 17M | ffmpeg-compile.tar.bz2 | 3.94 |
| 19M | ffmpeg-compile.tar.gz | 3.52 |
| 5.4M | ffmpeg-compile.tar.rz | 12.4 |
It works rather well. But does an unbuilt version of the same source compress better?
| Size | Filename | Ratio |
|---|---|---|
| 30M | ffmpeg-unbuilt | 1.0 |
| 4.0M | ffmpeg-unbuilt.tar.bzip2 | 7.5 |
| 5.2M | ffmpeg-unbuilt.tar.gz | 5.77 |
| 2.3M | ffmpeg-unbuilt.tar.rz | 13.0 |
Yes, it would appear to compress better. Text has more redundancy than binary files, after all.
But how much is the compression affected by the fact that these are subversion working copies? Let's see
| Size | Filename | Ratio |
|---|---|---|
| 13M | ffmpeg-nosvn | 1.0 |
| 2.1M | ffmpeg-nosvn.tar.bz2 | 6.19 |
| 2.5M | ffmpeg-nosvn.tar.gz | 5.2 |
| 2.1M | ffmpeg-nosvn.tar.rz | 6.19 |
Yes, the compression ratios are affected substantially: rzip loses its lead once you strip out the redundant files in the .svn directories. Rzip is also proportionately better at compressing the version with binaries than any of the other compression methods, though the compression on that set of files is lackluster. Compressing builds of programs should -- in general -- be avoided.
Comments
Post new comment