From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <49f4ecd675aedd87fdd2700eefa7b46e@plan9.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] killing processes
Date: Fri, 16 Sep 2005 07:42:24 -0600
From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
In-Reply-To: <200509161321.j8GDLQi03539@zamenhof.cs.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 8b37b810-ead0-11e9-9d60-3106f5b1d025

>> Are you using caching?
> 
> not that I'm aware of.

I have.

> 
>> Would/does it make a difference?
> 
> good question.
> experience, anyone?

not for compilation.  as it creates object files and binaries it
necessarily needs to write absolutely everything past the cache and
onto the file server mounted.  on a sufficiently fast connection one
actually sees a slowdown when compared with non-cached compilations.
for any other general access caching really helps.

not all news are bad though -- one can boot from a remote file server
(presumably with caching) and edit the files locally (with all the
benefits of a very small response time) and cpu to a remote cpu server
just for the compilation.  i, for example, run 'win' in acme, cpu
close to the file server and keep a compile string handy on the top of
the window.

this all assumes that the uplink (writing to the file server) is the
slow part of the connection, which is the case with most home
dsl/cable providers.