for those stuck on a journaled filesystem and cant reparition or change for whatever reasons look into using laptop-mode without using hdparm to spin down the disks it will prevent small writes all the time for as long as you tell it till memory is full and it has to write it to disk or the timer hits and it does one massive write instead of many small ones
On Wed, 05 Jan 2005 18:20:48 -0600, Daniel Goller <[EMAIL PROTECTED]> wrote: > dont forget: > > use a non journaled filesystem like ext2 (yes i tried them all, > reiserfs, reiser4, xfs, ext3, ext2 wins on compile time) on /var/tmp/portage > talking about hard drives, most people might not have enough ram to toy > with using ram for /var/tmp/portage (which would be great, no doubt)(but > w/o enough ram you might end up using the swap alone if gcc like most of > your ram ) > > choose /var/tmp/portage's physical location where your disk is fastest > (side note, having an partition for it alone will keep compile times > more constant as it wont change physical location on the drive while our > disks fill up, instead it is always in the same spot) > > dont leave your flash filled tabs open in firefox (or your favorite > (tabbed) browser) it does add up having 3-4 flash add filled tabs open > while you compile > > emerge in a screen or best emerge foo &> /dev/null > > dont log (so do not use PORT_LOGDIR ) (your harddrive's head will fly > from /var/tmp/portage to the area your logdir is and back, if you must > keep the dir on that same partition) > > emerging while watching it in a terminal with AA fonts costly being > render will kill your compile times, so dont do it > (for those of you ever doing a emerge --sync on a remote box while > watching the files fly by on the local box will know the 100% cpu usage > that can cost you, dont think this wouldnt happen when compiling(im > aware some systems will be better than others, so noone needs to comment > they can do it w/o seeing said cpu usage, good for you)) > > do not use ccache in FEATURES, unless you expect to compiling the same > thing often, if you are an avg user who merges something and then uses > it till he/she upgrades, ccache will increase the first compile time, > thus if it is your only time you just increased compile time instead of > bringing it down (now if you are ChrisWhite tracking down a peskly > mplayer bug, you might like ccache temporarily) > > there might be more i cant think of right now, but those points should > help avoid common mistakes or help rethink your next drive's partitioning > > ok, here is a silly one: only compile after a reboot from console with > emerge foo &> /dev/null > > > Ciaran McCreesh wrote: > > >On Wed, 5 Jan 2005 22:55:12 +0000 Stuart Herbert <[EMAIL PROTECTED]> > >wrote: > >| I'd like to put together a doc full of advice on what users can do to > >| reduce how long it takes to build packages. I'm sure that there's > >| plenty of you with your own opinions on this, so let's have it ;-) > > > >Don't use c++ apps. > >Buy a lot more RAM. > >Switch to SCSI or FC hard drives. > >Turn off as many USE flags as you can get away with. > >Mount /var/tmp/portage on tmpfs. > >Avoid silly CFLAGS. > >Don't compile whilst mplayer is running. > >Turn off CPU frequency scaling. > > > > > > > > > -- [email protected] mailing list
