2014-09-04 4:10 GMT+09:00 Christian Kastner <deb...@kvr.at>: > On 2014-09-03 13:10, Changwoo Ryu wrote: >> 2014-09-03 17:04 GMT+09:00 Simon McVittie <s...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caee2ifwhycwfe3h_ddq2kpnrdjsydxmmclyeadah8jctbox...@mail.gmail.com
