# Quick Adjustment Faster Compile Time.

## jwm224

I'm new. My compile time was going slow during setup, so I did some alterations. 

I thought this article might interest all Gentoo users. It's just a few quick adjustments to speed up compile time. Hope this helps; it's definitely worth the time(that has dual meaning): 

http://eshlox.net/2012/07/29/gentoo-speeding-up-the-compilation-time/

Enjoy, Jay

----------

## NeddySeagoon

jwm224,

If you have enough RAM to put /var/tmp/portage into tmpfs,  then you don't need to to get the speed increase it promises.

It works like this.  If  /var/tmp/portage in tmpfs works then the kernel will keep everything in buffers anyway, so   /var/tmp/portage into tmpfs will not provide any speed increase.

However, it will save writes to disk which will never be read.  This is a good thing, especially on SSD.

The RAM bus bandwidth that would be used by the disk writes and the CPU cycles to set up the DMA transfers do disk are saved but this may not help with compile times.

It all depends where the bottleneck is in your system.

----------

## jwm224

That makes sense. I have less than a gig of ram. I have a gig plugged in, but the machine only registers 800mib+ (I can't remember the exact number...), but I'm installing Gentoo through Knoppix and it froze up during the night, compiling the genkernel. So, this morning, I plugged in an 8gb memory stick and used it for a swap space to give Knoppix something to fall back on. And, I set up that tmpfs in Gentoo's fstab. It seems to be working better now. Finger's crossed.

----------

## Irre

You can also speed up time by using another compiler. Clang or Fabrice Bellard's very fast Tinycc. In FreeBSD Clang is the default compiler. If Tinycc is usable I don't know...

----------

## NeddySeagoon

You can exchange compile time for execution time.

Higher levels of optimisation (up to a point) gives faster execution but extends the compile time because the compiler has to do more work.

-O0 gives good compile times but you won't like running the results, so don't try that at home.

----------

## szatox

 *Quote:*   

> Higher levels of optimisation (up to a point) gives faster execution

 

Not always. There is a negative side effect when going from 2 to 3: size of the binary increases by a relatively large value (i think it was roughly 30% or so) which effectively reduces CPU's cache size and in turn increases miss rate and then CPU is waiting for RAM instead of actually doing anything usefull. 

I don't consider levels higher than 3, as GCC drops those to 3 anyway. And when it didn't, it could even produce stuff too buggy to be usable. (Amarok with -O9 not plaing music anymore, anyone?  :Laughing:  Well, that was long long time ago)

Oh, and if we are at tuning emerge options, many packages don't allow massivly parallel compilations. They will only run in 1-3 threads, depending on phase, and that blog post doesn't mention --jobs and --load-average options that enable parallel emerge mode (multiple packages at the same time) while keeping total load at reasonable level when one of those packages is big enough to actually stress your box

----------

