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
next prev parent 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