home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / next / software / 2567 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  2.5 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!horga!reswi!reswi!ralf
  2. From: ralf@reswi.en.open.de (Ralf E. Stranzenbach)
  3. Newsgroups: comp.sys.next.software
  4. Subject: Re: nbuf=64/128 theory
  5. Date: 8 Nov 1992 23:17:49 GMT
  6. Organization: News Server fuer en.open.de
  7. Lines: 48
  8. Message-ID: <RALF.92Nov9001749@jodokus.en.open.de>
  9. References: <1992Nov8.130418.19237@wam.umd.edu>
  10. NNTP-Posting-Host: localhost.en.open.de
  11. In-reply-to: gaia@wam.umd.edu's message of Sun, 8 Nov 1992 13:04:18 GMT
  12.  
  13. >>>>> "L." == L. Anathea Brooks <gaia@wam.umd.edu> writes:
  14.  
  15.     L.> I've changed my boot params using nbuf=128 or rather nbu=128
  16.     L.> because of 12 character limit.
  17.  
  18.     L.> Now, I know this will speed up long compilations, perhaps
  19.     L.> various sorts of number crunching. BUT is there any advantage
  20.     L.> or speed gain in workaday world? I notice none, and wonder if
  21.     L.> the memory used by the buffer might be better used as just
  22.     L.> plain old memory.
  23.  
  24.     L.> I ask because I keep hearing people exclaim: "Change buffer
  25.     L.> size in boot params! You'll be amazed!" I'm not. BTW I have
  26.     L.> (only) 16 megs of memory in this NS Turbo.
  27.  
  28.     L.> This has been discussed but only as per instructions to change
  29.     L.> parameters, not vis a vis advantages/disadvantages.
  30.  
  31. The .nib file containing nearly all user-interface-objects changed
  32. from beeing a file (2.x) to directory (3.x). While this decision has
  33. some advantages, this has some drawbacks when used with a small block
  34. buffer cache.
  35.  
  36. Under 2.x the .nib-file gets mapped into the virtual memory when
  37. opened and stays there. This took a single directory scan and a single
  38. open/close pair.
  39.  
  40. Nowaday the .nib-"file" is a directory. Therefore one scan, open/close
  41. and read is required for each member of the .nib. Unfortunately there
  42. are a lot more files than one knows...
  43.  
  44. And this is the point, where the increased block-buffer cache speeds
  45. the system. Directory information can be kept (only ?) in the buffer
  46. cache. Because of the frequent open/close operations, even from within
  47. the kernel's namei algorithm, that otherwise would take their way to
  48. the disk, the system acts faster.
  49.  
  50. But you're right. There are a lot more better ways to use the main
  51. memory... But until we get realy fast disk subsystems we must pay
  52. memory for speed.
  53.  
  54.     - ralf
  55. --
  56. Ralf E.Stranzenbach  -   (NeXT)-Mail: ralf@reswi.en.open.de
  57.                                 Fido: Ralf_Stranzenbach 2:245/5800.12
  58.                        (Voice)-Phone: +49 2302 / 68403
  59. --
  60. Nullum est magnum ingenium sine mixtura dementioe.
  61.