🚀 go-pugleaf

tfb@aisb.ed.ac.uk (Tim Bradshaw) writes:

>I would *like* to use the subdirectory searching features for i.e
>TEXINPUTS that recent versions of web2c provide, so I can keep all
>sorts of packages isolated & not have to recompile TeX all the time.

>The performance is awful: 5-6 seconds to the `This is TeX' prompt on
>an unloaded Sun ELC with local disk, cf some tenths of a second with
>an older TeX.

There seems a huge difference between machines --
has it something to do with NFS?
On our main machine (Mips) there is no noticable downgrading.
But on other machine which should be faster
there is definitely a problem.

How does the speed compare with that of Unix "find"?

>If there is in fact no way to get it usable, then a compromise scheme
>might be to have single-level subdir searching.  This gives most of
>the advantages of multi-level but keeps the performance since you only
>need to stat the files in the top directory.  Lucid Emacs uses this
>approach with success.

Couldn't this be left to the user?
Eg a\b\c\\ in TEXINPUTS could mean search recursively,
while a\b\c\ could mean search first-level only.

>Alternatively some file could be put somewhere which TeX & METAFONT
>read to get a list of directories to search for stuff.  This at least
>keeps the effort of reconfiguring it small cf recompiling everything.

I feel that before doing anything complicated,
one needs to determine the source of the problem.
I wonder if it could lie in the recursion?
and that running through the directory first,
just marking sub-directories for later attention,
rather than going down them at once,
might not speed things up?

After all, it {\em should} only take nanoseconds
to run through a directory.


-- 
Timothy Murphy  
e-mail: tim@maths.tcd.ie
tel: +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland