lkml.org 
[lkml]   [1996]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory upgrade: not faster / nfs
Bryn Paul Arnold Jones wrote:
> On Sat, 26 Oct 1996, Olaf Kirch wrote:
> > : Compiling is a very I/O intensive task (all the
> > : include files, the compiler, the .I .S .o files).
> > Indeed. Read caching helps a bit here, but not much. It seems that
> > compiling is particularly slow because gcc writes out data in very small
> > chunks, and since writes are not cached, each write operation causes
> > and RPC call to the server. Try to watch NFS with tcpdump when doing
> > a compile...
> I think there is some option that makes the compiler write out in bigger
> blocks, it's either a gcc option, or a rebuild the libc, and define this I
> can't rember which, but it was discussed on this list some time ago, so
> perhaps you should look in an archive for it (Looking at ld's man page,
> and info pages it's either quite obscure, or not part of ld ...).
Howsabout -pipe? Saves you all the intermediate files except the
.o's...and would cut those out too if it weren't for that "separate
compilation" thing. Plus, ramdisks are your friend...a version of tmpfs
which doesn't crash the system for lack of memory when you cat /dev/zero
> /tmp/foo (or otherwise fill up /tmp) which could run in a ramdisk (which would be only one of the swap spaces) would do wonders for diskless systems...

Keith

--
"It moved faster. I swear, they are evolving right before my eyes. If
you see something this big, with eight legs coming your way, let me
know;
I have to kill it before it develops language skills."
--- Ambassador Londo Mollari, in 'Sic Transit Vir' (Babylon 5)

\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.062 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site