Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
2014-09-04 4:10 GMT+09:00 Christian Kastner <debian@kvr.at>:
> On 2014-09-03 13:10, Changwoo Ryu wrote:
>> 2014-09-03 17:04 GMT+09:00 Simon McVittie <smcv@debian.org>:
>>> On 02/09/14 21:17, Changwoo Ryu wrote:
>>>> For fonts-nanum, the default is ~300 KiB 3.5% larger than -9e. And -9e
>>>> is not better than -8e.
>>>
>>> I don't think anyone is arguing that higher compression settings don't
>>> produce better compression ratios. However:
>>>
>>> Preset DictSize CompCPU CompMem DecMem
>>> ...
>>> -6 8 MiB 6 94 MiB 9 MiB <-
>>> -7 16 MiB 6 186 MiB 17 MiB
>>> -8 32 MiB 6 370 MiB 33 MiB <-
>>> -9 64 MiB 6 674 MiB 65 MiB
>>>
>>> ... it's about cost/benefit. If we can save 300 KiB of compressed size,
>>> but the cost is to more than triple the required memory to decompress
>>> (from 9 MiB to 33 MiB), is that actually a worthwhile trade-off?
>
> That is the key question, and I believe considering the worst possible
> cost -- a package that cannot be unpacked, as in #757740 -- the
> trade-off is not worth it.
>
>> I think yes. The cost is 24 MiB extra memory on installation, and
>> benefits are bandwidth and mirror size saving of big packages.
>
> I think you are overestimating the benefits, and underestimating the costs.
>
> Benefits: from the numbers posted in this thread, the size savings
> compared to the default compression level for some sample packages are
> somewhere around 3% to 4%. I claim that *practical* benefits from this
> saving are insignificant to minor at best; counter-examples to this
> claim are welcome.
The numbers and ratios are bigger for bigger packages. For
texlive-latex-extra-doc, -9e option shrinked 30 MiB (10%) size
(#675537).
> Costs: The difference, to the default setting, in memory requirement may
> be only 24MiB, but you forget that with this increase, you're definitely
> crossing the 64MiB barrier. That is a common size for the amount of
> physical RAM in embedded devices, and I believe that barrier should be
> tested only for good reasons, otherwise stuff like #757740 happens.
I fully agree on #757740. libkeyutils and many packages are expected
to be installed on lowmem machines. Such packages should not override
xz level, and packages in base system are using gzip for bootstrapping
without swap.
But for big packages, I don't even think they need to be installed on
lowmem embedded machines. Such big packages are expected to be used on
desktop machines. What's the point of supporting 50MB Truetype fonts
and 400MB texlive-latex-extra-doc installation in 64MB devices which
fortunately have enough storage and have no real use of those
packages? It doesn't happen in practice.
> And finally, the cost of deviating from a default setting itself, and
> the implications for when that default changes, should be considered.
Modifying one or two lines of debian/rules in well known way is
trivial. On possible default changes, expected maintanance action is
also one line of trivial modification.
>> I think we can assume usual desktop machines for font packages.
>> According to the d-i manual, wheezy's minimum RAM "for desktop" is 128
>> MiB, and 512 MiB is recommended. For jessie, the minimum is 256 MiB
>> and 1 GiB is recommended.
>
> OK, but to me, that assumption seems contradictory to the motive of
> reducing package size. If we are assuming a sufficiently spec'ed system,
> say where at least 512MiB are the norm, then the cost might be
> tolerable, but at the same time, the 3% to 4% savings in package size
> will hardly benefit you.
High spec machine does not give me better bandwidth or smaller Debian
mirror space. Even though I live in Seoul where the world fastest
connection is available, several seconds of package download time
matters to me.
>> And these requirement/recommendation are far behind of the current
>> computer market.
>
> For desktop and laptop computers, yes. However, embedded devices, which
> are becoming increasingly popular, are often memory-constrained.
As I said, such lowmem embeded devices don't even need to install big packages.
Reply to: