home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / text / tex / 10574 < prev    next >
Encoding:
Internet Message Format  |  1992-08-26  |  2.8 KB

  1. Path: sparky!uunet!stanford.edu!unix!hsdndev!news.cs.umb.edu!karl
  2. From: karl@cs.umb.edu (Karl Berry)
  3. Newsgroups: comp.text.tex
  4. Subject: Re: Web2c and subdirectory searching
  5. Message-ID: <KARL.92Aug26195026@ra.cs.umb.edu>
  6. Date: 27 Aug 92 00:50:26 GMT
  7. References: <TFB.92Aug13021349@eagle.aisb.ed.ac.uk> <1992Aug13.020719.1100@maths.tcd.ie>
  8.     <TFB.92Aug13084631@helium.aisb.ed.ac.uk>
  9. Sender: news@cs.umb.edu (USENET News System)
  10. Reply-To: karl@cs.umb.edu
  11. Organization: University of Massachusetts at Boston
  12. Lines: 52
  13. In-Reply-To: tfb@aisb.ed.ac.uk's message of 13 Aug 92 07: 46:31 GMT
  14. Nntp-Posting-Host: ra.cs.umb.edu
  15.  
  16.  
  17.     find takes about 2 secs to traverse the same tree, which is still
  18.     pretty slow, but faster than TeX.
  19.  
  20. Is GNU find faster than TeX?  If so, something strange is going on,
  21. because ...
  22.  
  23.     What I did find was that the code is incredibly bright about working
  24.     out if a directory *has* subdirs -- it counts the links and assumes
  25.     that if there are only 2 then it hasn't.
  26.  
  27. ... I stole this trick (fortunately not patented yet, at least to my
  28. knowledge) from GNU find.  A user (I forgot who, unfortunately) posted
  29. the fix to bug-gnu-utils.
  30.  
  31. I suggest running tex under gdb (or some debugger), and seeing if in
  32. fact the ``incredibly bright'' code is actually working.  As you
  33. describe your setup, the only directories that should be readdir'd are
  34. the top-level ones, which is only 4 or 5.  Obviously it is stat-ing all
  35. the hundreds of input files.  The question is why.  If you have
  36. any subdirectories at all, the link-counting trick fails, and all
  37. directory entries must be stat-d.
  38.  
  39. You also suggest one-level subdirectory searching:
  40.  
  41.     If there is in fact no way to get it usable, then a compromise scheme
  42.     might be to have single-level subdir searching.  
  43.  
  44. This is what I implemented first (before I came across the link-counting
  45. trick); it got released in 5.84, I think.  I don't see why this would be
  46. any faster than the recursive case, though, if the directory hierarchy
  47. is right for subdir searching.  (If it isn't, you'll probably lose
  48. either way.)
  49.  
  50. You also suggest, as a final stopgap, having TeX etc. read directory
  51. paths from a file.  I'd prefer not to have an additional configuration
  52. file around for installers to have to think about.
  53.  
  54. I'm not sure if I made any significant changes to the path searching
  55. code after I released 5.851c.  But you might want to grab dvipsk.tar.Z
  56. or xdvik.tar.Z and copy the common files into web2c's lib/ directory,
  57. just in case.
  58.  
  59. By the way, messages like this about web2c are usually best directed at
  60. me via mail (copy to the list as well if you want).  It was purely
  61. fortuitous that I happened to be reading news for a little while before
  62. your article expired.
  63.  
  64. Thanks for the note.
  65. --
  66. karl@cs.umb.edu
  67. Member of the League for Programming Freedom---write to league@prep.ai.mit.edu.
  68.