From: Phil Blundell <philb@gnu.org>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: sstate compression
Date: Wed, 04 Jan 2012 15:05:34 +0000 [thread overview]
Message-ID: <1325689535.28005.59.camel@phil-desktop> (raw)
Has anybody experimented with the effects of using different/no
compression for the sstate packages?
I happened to notice that, for one of my builds, oe was spending a
noticeable amount of time gzipping the tarfiles for sstate. Obviously
this indicates that I should get myself a better computer, but I do
wonder whether there is a different tradeoff that can be made here.
Taking one of my webkit sstate archives as an example, the uncompressed
tarfile is 112M.
gzip (default compression) reduces this to 28M in about 4.2 seconds.
gzip -1 reduces it to 33M in about 1.75 seconds.
lzop reduces it to 40M in about 0.75 seconds.
Presumably the same sort of considerations apply to the compressed data
inside .ipks, though of course the file sizes there tend to be rather
smaller so I guess the impact is less.
I'm currently setting GZIP="-1" in my local configuration since that's
easy to arrange and seems to produce a worthwhile benefit. It's not
totally obvious to me whether switching to lzo would be a net win or a
loss, but either way this would involve hacking sstate.bbclass and I was
too lazy to do that so far.
p.
next reply other threads:[~2012-01-04 15:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-04 15:05 Phil Blundell [this message]
2012-01-04 15:33 ` sstate compression Richard Purdie
2012-01-04 16:31 ` McClintock Matthew-B29882
2012-01-04 16:32 ` Chris Larson
2012-01-04 16:41 ` Phil Blundell
2012-01-04 16:47 ` Richard Purdie
2012-01-04 16:53 ` Phil Blundell
2012-01-04 16:58 ` Richard Purdie
2012-01-04 16:55 ` McClintock Matthew-B29882
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=1325689535.28005.59.camel@phil-desktop \
--to=philb@gnu.org \
--cc=openembedded-core@lists.openembedded.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox