home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / next / software / 2559 < prev    next >
Encoding:
Text File  |  1992-11-08  |  1.4 KB  |  38 lines
  1. Newsgroups: comp.sys.next.software
  2. Path: sparky!uunet!pipex!demon!seer.demon.co.uk!paul
  3. From: paul@seer.demon.co.uk (Paul Lynch)
  4. Subject: Re: nbuf=64/128 theory
  5. Message-ID: <1992Nov8.220956.491@seer.demon.co.uk>
  6. Sender: paul@seer.demon.co.uk
  7. Organization: P & L Systems
  8. References: <1992Nov8.130418.19237@wam.umd.edu>
  9. Date: Sun, 8 Nov 1992 22:09:56 GMT
  10. Lines: 26
  11.  
  12. In article <1992Nov8.130418.19237@wam.umd.edu> gaia@wam.umd.edu (L.  
  13. Anathea Brooks) writes:
  14. > 
  15. > I've changed my boot params using nbuf=128 or rather 
  16. > nbu=128 because of 12 character limit.
  17. > 
  18. > Now, I know this will speed up long compilations, perhaps
  19. > various sorts of number crunching. BUT is there any advantage 
  20. > or speed gain in workaday world? I notice none, and wonder if 
  21. > the memory used by the buffer might be better used as just 
  22. > plain old memory. 
  23.  
  24. Are you running 3.0?  If so, you should see a noticeable speed  
  25. improvement, particularly when scrolling text windows (such as in Edit)
  26.  
  27. Also, are you sure that you typed it in correctly.  If so, the first  
  28. messages in a verbose boot should confirm the number of buffers in use.   
  29. The only indication that you get of an incorrect parmeter is that the  
  30. number of buffers reported is 16.
  31.  
  32. Paul
  33. -- 
  34. Paul Lynch
  35. P & L Systems                   (NeXTmail) paul@seer.demon.co.uk
  36. Tel: (0494)671501                      paull@cix.compulink.co.uk
  37. Fax: (0494)680228                       76711.451@compuserve.com
  38.