🚀 go-pugleaf

In article <91115.231110RFM@psuvm.psu.edu> RFM@psuvm.psu.edu writes:
>why not do *both* ? A couple of points: (1) When it comes to allocating
>ram to disk caching, *MORE* is not necessarily better.  I've read this
>in various discussions about disk caching, and I beliee it. In my own
>case, I get better numbers out of the Norton speed ratings with 128k
>in a disk cache than I do with 256 or 512k (all in EXPANDED mem, BTW).

There is some truth to this.  If you have an inefficient cache program
or a slow-turkey computer, it may actually take the system longer to
search through the cache than to just read it off the hard drive.  Of course,
the more memory you have allocated to the cache the longer the search time.
A perfect example of a bad cache is the BUFFERS= statement in CONFIG.SYS.
I've heard that this DOS cache uses no indexing, and simply searches the
memory sequentially, looking for data.  On a slow computer, if you set
your BUFFERS too high, you'll actually get worse performance.  Of course,
the DOS cache is just about the least efficient known to man, but the
principle can also apply to badly written caches.
If you notice that a 256K cache actually slows down disk reads, you
should probably get a new caching program.

-- 
+==========================================================================+
| Noam Mendelson   ..!ucbvax!web!c60b-1eq       | "I haven't lost my mind, |
| c60b-1eq@web.Berkeley.EDU                     |  it's backed up on tape  |
| University of California at Berkeley          |  somewhere."             |