public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Richard Fish <bigfish@asmallpond.org>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Howto speed up compilations
Date: Mon, 18 Jul 2005 21:06:16 +0200	[thread overview]
Message-ID: <42DBFDA8.10005@asmallpond.org> (raw)
In-Reply-To: <42DBECFD.5060506@gmail.com>

Zac Medico wrote:

> John J. Foster wrote:
>
>>
>> OK, this happens all the time. I search, can't find what I want, post a
>> question, search again, and there it is. This is not the "thread" I was
>> talking about, but it was right in front of me on the Gentoo Wiki.
>> http://gentoo-wiki.com/TIP_Speeding_up_portage_with_tmpfs
>>
>> Does anyone have any "tips" on these "tips"?
>>
>
> I sincerely doubt that this technique is worth the trouble because the 
> Linux virtual memory system will automatically cache frequently 
> accessed files in ram.  The tmpfs will eliminate filesystem overhead 
> and will certainly result in a reduction of total build time.  
> However, I'd go with Bruno's recommendation and just put -pipe in the 
> cflags.  For builds that work well in parallel, which most large 
> builds do, distcc is a great way to speed things up.
>
> Zac


I'm a bit dubious about this well...unless you have a huge amount of 
memory (as in, more than 2G).  But even then, if you have sufficient 
RAM, most of the source files should still be in memory as a result of 
the extraction of the source archive before compilation.  And if buffers 
get flushed/recycled as a result of the compilation, that generally 
means that the compiler needed a large amount of memory, and giving the 
compiler your RAM is a much better choice, as otherwise swap has to be 
used, and that will *kill* your compilation time!

That isn't to say that I don't think some smart and simple things beyond 
-pipe can speed up builds.  I believe /var should be it's own 
filesystem, about 5G in size, and positioned just before /usr if you 
have one, or just after / if not.  The filesystem should be either XFS 
(caches files in memory very agressively, and in fact doesn't even 
update the disk for short-lived temporary files) or reiserfs v3 (creates 
and deletes files very very quickly).

However, I can pretty much guarantee that nothing short of a 
16-processor, 16GB system (or a distcc farm, as Colin suggested) will 
allow you to "emerge -Dv --emptytree kde-meta" in 15 minutes!!!  There 
is simply no getting around the CPU and memory bandwidth required for 
compiling!

-Richard

-- 
gentoo-user@gentoo.org mailing list



  reply	other threads:[~2005-07-18 19:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-18 17:07 [gentoo-user] Howto speed up compilations John J. Foster
2005-07-18 17:14 ` Bruno Lustosa
2005-07-18 17:55   ` Neil Bothwick
2005-07-18 18:40     ` Colin
2005-07-18 18:55       ` John J. Foster
2005-07-18 19:01       ` Daniel da Veiga
2005-07-18 17:19 ` John J. Foster
2005-07-18 17:55   ` Zac Medico
2005-07-18 19:06     ` Richard Fish [this message]
2005-07-18 17:23 ` David Morgan
2005-07-18 17:26 ` [gentoo-user] " Francesco Talamona
2005-07-18 21:39   ` Nick Rout
2005-07-19 10:03 ` [gentoo-user] " Rafer
2005-07-19 21:11   ` Zac Medico

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=42DBFDA8.10005@asmallpond.org \
    --to=bigfish@asmallpond.org \
    --cc=gentoo-user@lists.gentoo.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