public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Joseph Myers <joseph@codesourcery.com>,
	Matthias Klose <doko@ubuntu.com>,
	       GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [patch] build xz (instead of bz2) compressed tarballs and diffs
Date: Mon, 15 May 2017 18:38:00 -0000	[thread overview]
Message-ID: <20170515142416.GF3567@laptop.zalov.cz> (raw)
In-Reply-To: <20170515141344.GB27845@x4>

On Mon, May 15, 2017 at 04:13:44PM +0200, Markus Trippelsdorf wrote:
> On 2017.05.15 at 14:02 +0000, Joseph Myers wrote:
> > The xz manpage warns against blindly using -9 (for which --best is a 
> > deprecated alias) because of the implications for memory requirements for 
> > decompressing.  If there's a reason it's considered appropriate here, I 
> > think it needs an explanatory comment.
> 
> I think it is unacceptable, because it would increase memory usage when
> decompressing over 20x compared to bz2 (and over 100x while compressing).

The memory using during compressing isn't that interesting as long as it
isn't prohibitive for sourceware or the machines RMs use.
For the decompression, I guess it matters what is actually the memory needed
for decompression the -9 gcc tarball, and compare that to minimal memory
requirements to compile (not bootstrap) the compiler using typical system
compilers.  If compilation of gcc takes more memory than the decompression,
then it should be fine, why would anyone try to decompress gcc not to build
it afterwards?

	Jakub

  reply	other threads:[~2017-05-15 18:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-15  1:35 Matthias Klose
2017-05-15 14:11 ` Joseph Myers
2017-05-15 14:15   ` Markus Trippelsdorf
2017-05-15 18:38     ` Jakub Jelinek [this message]
2017-05-15 19:13       ` Markus Trippelsdorf
2017-05-23 23:22         ` Matthias Klose
2017-05-18 10:41 ` Richard Biener
2017-05-23 23:56   ` Matthias Klose
2017-05-24  7:23     ` Richard Biener
2017-05-24 19:21     ` Gerald Pfeifer

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=20170515142416.GF3567@laptop.zalov.cz \
    --to=jakub@redhat.com \
    --cc=doko@ubuntu.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=joseph@codesourcery.com \
    --cc=markus@trippelsdorf.de \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).