[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The archive now supports xz compression

On 2011-08-11, Adam Borowski <kilobyte@angband.pl> wrote:
>> Think of both user systems and the Debian buildds which will waste more
>> time - an especially bad problem on slower architectures.
> The gain is especially meaningful for slower architectures, as they tend to
> have less disk space and slower network links (arm tends to be used in
> phones).  No extra memory is needed -- decompression is not done in parallel
> with memory-hungry stages of dpkg's work.  The decompression, merely 2.5
> times slower than with gzip, is a tiny fraction of what dpkg takes.

It takes a lot longer to compress on slower architectures (i.e. on the
buildds), though.  You could've built a whole package in that time.  (Resorting
to your style of argument.)

>> Please remember that packages in the base system[1] (and dependencies)
>> *must* currently use gzip as otherwise debootstrap will be unable to
>> install a system.
>> 1: Meaning everything with Priority: required.
> I'm not as strongly opinionated here, but I guess decreasing the size of d-i
> images would be a huge win as well.

You cannot debootstrap it anymore.  I can hardly call that a win.  (So we'd
need to wait a few releases for that.)

> [1]. Three calls of system() could be avoided for little effort and two more
> for substantial effort -- and all of them could be turned into execve(), but
> otherwise, it's pretty much as fast as you can get.  With package build time
> below a single disk seek, further optimizations are pointless.  The point of
> "goodbye" was abuse of policy and buzzword compliancy, not speed.

It compiles the same script multiple times during build.

Kind regards
Philipp Kern

Reply to: