From: Denys Vlasenko <vda.linux@googlemail.com>
To: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: Al Viro <viro@ftp.linux.org.uk>,
Jan Engelhardt <jengelh@computergmbh.de>,
linux-kernel@vger.kernel.org, apiszcz@solarrain.com
Subject: Re: In response to kernel compression e-mail a few months ago.
Date: Tue, 16 Oct 2007 14:19:07 +0100 [thread overview]
Message-ID: <200710161419.07975.vda.linux@googlemail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0710141650500.12466@p34.internal.lan>
On Sunday 14 October 2007 21:58, Justin Piszcz wrote:
>
> On Sun, 14 Oct 2007, Al Viro wrote:
>
> > On Sun, Oct 14, 2007 at 09:46:15PM +0200, Jan Engelhardt wrote:
> >> (Obviously we shall pick .7z)
> >
> > The hell it is. Take a look at memory footprint of those suckers...
>
> For compression with -mx=9 it does use 500-900 MiB of RAM, that is true.
> For decompression, 50-70 MiB.
I'm with Al on this. 50 Mb for decompression?
Embedded and small device folks will not love this, I'm sure.
*Maybe* we can use lzma. Seems to use 8Mb on decompression:
PID VSZ*VSZRW RSS (SHR) DIRTY (SHR) STACK COMMAND
30474 10708 8604 8760 392 8360 0 8 lzmacat pld-th-x86_64.tar.lzma
(pld-th-x86_64.tar.lzma is a random 40Mb .lzma file I found on the net)
Sizes in Kb again:
32392 linux-2.6.16.17.tar.7z
33520 linux-2.6.16.17.tar.lzma
P.S. sorting files by extension in tarball generally helps, but in case
of Linux kernel, they are all C code anyway, so no measurable gain there.
--
vda
next prev parent reply other threads:[~2007-10-16 13:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-14 19:34 In response to kernel compression e-mail a few months ago Justin Piszcz
2007-10-14 19:46 ` Jan Engelhardt
2007-10-14 19:53 ` Justin Piszcz
2007-10-14 20:04 ` Jan Engelhardt
2007-10-14 20:16 ` Justin Piszcz
2007-10-14 20:50 ` Al Viro
2007-10-14 20:58 ` Justin Piszcz
2007-10-14 21:48 ` Jan Engelhardt
2007-10-14 22:28 ` Justin Piszcz
2007-10-16 13:19 ` Denys Vlasenko [this message]
2007-10-16 13:31 ` Andreas Schwab
2007-10-16 20:54 ` Denys Vlasenko
2007-10-16 14:22 ` Jan Engelhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200710161419.07975.vda.linux@googlemail.com \
--to=vda.linux@googlemail.com \
--cc=apiszcz@solarrain.com \
--cc=jengelh@computergmbh.de \
--cc=jpiszcz@lucidpixels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.