[14181] in Athena Bugs
[daemon@ATHENA.MIT.EDU : Re: TeX tree in AFS]
daemon@ATHENA.MIT.EDU (Marc Horowitz)
Sun Feb 11 17:30:27 1996
Date: Sun, 11 Feb 1996 17:30:22 -0500
From: Marc Horowitz <marc@MIT.EDU>
To: bugs@MIT.EDU, bug-sipb@MIT.EDU
Cc: bert@MIT.EDU
We might want to take advantage of the ls-R feature in our
environment.
Marc
------- Forwarded transaction
[4528] daemon@ATHENA.MIT.EDU (Michael D Sofka) Info-AFS_Redistribution 02/09/96 16:04 (58 lines)
Subject: Re: TeX tree in AFS
To: rpi-mail-afs@usenet.rpi.edu
From: sofkam@rpi.edu (Michael D Sofka)
Date: 09 Feb 1996 18:38:11 GMT
In-Reply-To: mike@msc.cornell.edu's message of Fri, 9 Feb 1996 04:50:37 GMT
>Current releases of TeX don't put all the font information in one
>subdirectory any more. Not only is the information split up by different
>font styles but also for different devices. Startup times for TeX to
>search the directory tree from AFS versus a local disk is about 10x.
The time is because the kpathsea library will search all sub-directories
of a path if its separator is //. So, for example, we have:
TEXINPUTS=/campus/tex/tex/3.1415/common/lib/tex//
which searches tex/ams, tex/eplain, tex/latex2e, etc. This is much
easier then specifying all the paths. Two things slow this down:
1. If any of the directories contain a mixture of files and
directories the search takes longer. This is because kpathsea
assumes that a directory with exactly 2 links contains only
files (same trick is used in gnu-find). If there are more then
two links, each entry must be stat'ed to see if it is a file
or a directory.
2. AFS access to all these directories (particularly the stats)
can take a *very* long time compared to local disk, or nfs.
What we did, was use the ls-R ``database.'' That is, if a file called
ls-R exists on the TEXMF path it will read it as a recursive directory
listing, and parse the contents to find files. That is, one file is
opened, and this one file tells kpathsea where the other files are located.
If the target file isn't found in ls-R, then the directories will be
searched (slowing things down again). This directory search can be
completely suppressed by starting a path element with !!. E.g.,
PKFONTS=.:!!/campus/text/tex/3.1415/common/lib/fonts/pk//
will cause xdvi and dvips to search for pk files in all sub-directories
of /campus/.../fonts/pk/ that are found in the ls-R file. If a file is
not found no other search is made. This trimmed a small amount of time from
TeX (for input and tfm files) and dvips, but a huge amount of time from
xdvi, which does lots of attempted fopen()s for fonts at various sizes.
(Note, the time savings for latex2e is considerably more, since latex2e
has nots of input files to find and load.)
The kpathsea.texi file contains a complete description of how paths are
searched, and how the ls-R file works. I'll be glad to help if you have
any questions, but since this isn't really an AFS problem, how about we
take it off-list.
Mike
--
--
Michael D. Sofka sofkam@rpi.edu
ITS Systems Programmer TeX, AFS, NIS, NTP, Astronomy, Epistemology.
Rensselaer Polytechnic Institute, Troy, NY. http://www.rpi.edu/~sofkam/
--[4528]--
------- End forwarded transaction
