🚀 go-pugleaf

>>>>> On 13 Aug 92 02:07:19 GMT, tim@maths.tcd.ie (Timothy Murphy) said:

> (Tim Bradshaw) writes:

>> [Tex with subdirectory searching is sloow]

> 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"?

find takes about 2 secs to traverse the same tree, which is still
pretty slow, but faster than TeX.  Does the MIPS machine have a BSD
filesystem? 

>> [I suggested single level subdir searching]

> 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.

Yes I think that would be a good way of doing it.  I almost
implemented this last night but gave up...

> 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.

No I think it should take quite a while.  The directory-ness of a file
is stored in the inode not the directory entry so you have to do a lot
of work.  But perhaps it is plausible that going breadth-first would
win, I'm not sure.

What I did find was that the code is incredibly bright about working
out if a directory *has* subdirs -- it counts the links and assumes
that if there are only 2 then it hasn't.  I don't see how it could do
significantly better than it does, unless there is something obvious
I'm missing.

--tim