Compressing packages with bzip2 instead gzip?
ubuntu at paul.sladen.org
Tue Jan 17 12:14:36 GMT 2006
On Mon, 16 Jan 2006, Phillip Susi wrote:
> Which is why we want to use 7zip, since it is twice as fast at
> decompressing as bzip2, and gets better compression.
I don't think you can generalise like. One of the (many) algorithms that
7zip selects between is bzip2, the other being bascially zlib with a huge
(out of spec) window size.
The reason that 7zip does better on jump-infested i386 code is that it runs
a pre-processor over the binary to convert relative jumps into absolute
values (and the absolute values are more likely to repeat).
I think there is a case for adding support for a post-processing stage to
dpkg/cloop (like PNG does with predictors). Secondly, if bzip2 speed is a
problem, I suspect there is room for optimisation (refactoring, _not_
turning on --omg-faster) and using bzip2 compression with a smaller
windowsize (<900kB) if the difference is less than 1% in size.
(For perspective, one seek() on the CD image is going to cost about the same
as the difference in execution speed of zlib/bzip2).
Delta-debs on Mirrors.
For mirror distribution, my conclusion from 12months ago was that zsync
(pre-computed, client-size executed rsync) against the data.tar regenerated
by dpkg-repack is the way to go.
Since this would go into APT, dpkg stays clean and
I like the idea in somebody else's email of only providing zsyncs against
files published on CD or the last 10days worth.
I think a *top* priority should be delta-diffs on the Package lists, but the
dapper-does-it-48-times-a-day churn on these is massive.
This country is covered in white fluffy snow. Helsinki, FI
More information about the ubuntu-devel