home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / ultrix / 9254 < prev    next >
Encoding:
Internet Message Format  |  1993-01-11  |  1.9 KB
  1. Path: sparky!uunet!haven.umd.edu!decuac!pa.dec.com!mogul
  2. From: mogul@pa.dec.com (Jeffrey Mogul)
  3. Newsgroups: comp.unix.ultrix
  4. Subject: Re: Any way to do a faster link??
  5. Date: 12 Jan 1993 00:40:19 GMT
  6. Organization: DEC Western Research
  7. Lines: 38
  8. Message-ID: <1it41jINNrjb@usenet.pa.dec.com>
  9. References: <1iqm8b$807@agate.berkeley.edu> <9301110245.AA08082@TIS.COM>
  10. NNTP-Posting-Host: jove.pa.dec.com
  11.  
  12. In article <9301110245.AA08082@TIS.COM> mjr@TIS.COM writes:
  13. >>I need to know if there is any way to speed up compile time on a DECstation
  14. >>5000? The bottle neck seems to be the linking portion of the compile cycle,
  15. >>especially, if some of the libraries are coming off of NFS.
  16. >
  17. >    NFS is the problem here. One gross kludge would be to have your
  18. >makefile maintain *copies* of the library on local disk. I have done this
  19. >in the past, and while it's *ugly* it works. I.e.:
  20.  
  21. What Marcus says is probably true, but it's not necessarily the whole
  22. truth.  His changes avoid some NFS read operations, which are marginally
  23. slower than reading from a local disk, but probably not so much slower
  24. (unless your NFS server is wimpy) that they account for the entire
  25. problem.
  26.  
  27. If your working directory is also NFS-mounted, then the real problem
  28. may be that NFS writes are awfully slow.  You can speed things up by
  29. installing PrestoServe on your NFS server, or by using NFS server code
  30. that does "write-gathering" (such as comes in ULTRIX 4.3), but the
  31. specific problem is that the loader tends to do all sorts of
  32. random-access writes to the final output file.  I think this is worse
  33. when lots of libraries are involved, since many more symbol references
  34. get resolved.
  35.  
  36. What I sometimes do is:
  37.  
  38. foo: /tmp/foo
  39.     cp /tmp/foo foo
  40.     rm /tmp/foo
  41.  
  42. /tmp/foo: foo.o $(LIBS)
  43.     cc -o /tmp/foo foo.o $(LIBS)
  44.  
  45. Believe it or not, this can run twice as fast as the more direct
  46. method (especially when lots of X libraries are used) because the
  47. "cp" command does the NFS I/Os in nice big chunks.
  48.  
  49. -Jeff
  50.