From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from munnari.oz.au ([128.250.1.21]) by archone.tamu.edu with SMTP id <45329>; Sat, 8 Feb 1992 05:02:19 -0600
Received: from cerberus.bhpese.oz (via metro) by munnari.oz.au with SunIII (5.64+1.3.1+0.50)
	id AA02039; Sat, 8 Feb 1992 22:01:59 +1100 (from Sm@cerberus.bhpese.oz.au)
Received: from localhost by cerberus.bhpese.oz.au with ELM 2.3 PL5
	id AA05781; Sat, 8 Feb 1992 22:01:08 +1100; sendmail 5.65c/Sm3.0RMSU
	(from Sm@cerberus.bhpese.oz.au for rc@archone.tamu.edu@munnari.oz.au)
Message-Id: <199202081101.AA05781@cerberus.bhpese.oz.au>
From: Scott Merrilees <Sm@cerberus.bhpese.oz.au>
Subject: path caching
To: rc@archone.tamu.edu (The rc Mailing List)
Date: Sat, 8 Feb 1992 16:01:07 -0600
X-Face: '82~l%BnDBWVn])DV^cl_%bla$T]kNbRN&]>v{ED9["<q!|zi"
	<,S3"#^"+3RJ1C?IxA1IY'1("D;SJy,u6fdNH=kP!MC_\"dq0f
	X-kWdVOnVcT:xjp+v5AbX#NJ3D$nXLP&)Xb&D5)NA4z#KaZBR

I've been playing with the idea of a file system based path cache, as
my path is rather long.  Enclosed is some doco I wrote on the caching,
and accompanying instrumentation.  This is currently for rc 1.2, I am
just about to post it to 1.3b.  Comments ?

Sm
--
Scott Merrilees, BHP Information Technology, Newcastle, Australia
Internet: Sm@bhpese.oz.au   Phone: +61 49 40 2132   Fax: ... 2165
--
Cachepath modifications.

This is an attemp to add a file system based command lookup cacheing to rc.

Cachepath is a normal rc variable that is the pathname of a directory
to use for storing the cache entries.  Cache entries are symbolic links
to the real program.  Cachepath should be inserted where you want it
to be searched in the path variable.  Programs that are found after the
position of cachepath in path are symlinked into the cachepath, hence,
subsequent lookup should find them in the cachepath first, rather than
their real directory.  This adds about 30 lines code to which().

eg:
	; cachepath = $home/.cache
	; mkdir $cachepath
	; path = ( /bin /usr/bin $cachepath ... )

The advantages I see in using a filesystem based cache:

1.	the contents of the cache are avaiable to all programs that
	use path lookup

2.	the cache is easily user modifable by the user via rm & ln -s.
	the cache can also be primed/trimmed as per user whim.

3.	user can specify where in the path cachepath works.

4.	I didn't have to modify the shell syntax to include a new
	command to manipulate the cache, ala rehash in csh (vomit)

5.	Should be nice & fast if cachepath is on a memory based file
	system.

disadvantages:

1.	requires symlinks.

2.	can chew up a few inodes

3.	I keep spelling cache as cahce.

4.	requires a special variable name, although it is only known in
	one place, which().

5.	requires a extra varlookup() per call to which(), and some
	extra streq()'s, but this is probably overshadowed by kernel
	overhead in the stat() in rc_access().


Pathstats modificiations.

After doing cahcepath, I wanted a way to evaluate the usefulness of
it.  I decided on a way to measure the number of hits to each path
component.  This is implimented as a list variable, pathstats, which
is a list of numbers, which correspond to path components.  Pathstats
is a kind of readonly variable, as it is overwritten each time which()
succeeds on a path lookup.   I intend to use this to test the
effectiveness of cachepath & to generally test the efficiency of the
current path order.  Overheads involved are a varlookup() and a
varassign() per call to which().  Unfortunately, when rc forks
internally, pathstats from the child aren't propagated back to the
parent, & I don't think it worthwhile to make it do so.  This also
adds about 30 lines to which().


	; pathstats = 0 # enable
	; ...		# use rc normally for a while
	; echo $pathstats
	137 6 5 1 1 0 0 0 0 0 0 0 0 0 1 1
	; echo $path
	/bin /usr/bin /p/Sm/.cache /usr/ucb /usr/local/bin
	/usr/bsd43/bin /etc /usr/etc /usr/local/etc /usr/new /usr/hosts
	/usr/bin/X11 /usr/spool/MHSnet/_bin /usr/local/gnu/bin
	/p/Sm/bin /p/Sm/bin/mipseb .