Author: Matt Deatherage
Year: 1988
... discusses effective use of the GS/OS cache.
Apple II
Technical Notes
_____________________________________________________________________________
Developer Technical Support
GS/OS
#3: Pointers on Caching
Written by: Matt Deatherage November 1988
This Technical Note discusses effective use of the GS/OS cache.
_____________________________________________________________________________
Introduction
GS/OS is the first Apple II operating system to offer a sophisticated caching
mechanism. However, using the cache and using it wisely are two different
things. This Note presents some concepts which should lead to higher
performance for your application if it uses the cache.
What's Cached Automatically?
All blocks on a GS/OS readable disk could be classified into one of two
categories. "Application blocks" are all blocks on the disk contained in any
file (except a directory file), while "system blocks" are other blocks on the
disk. System blocks belong to the file system and include directory blocks,
bitmap blocks, and other housekeeping blocks specific to the file system.
GS/OS always maintains at least a 16K cache, even if the user has set the disk
cache size to 0K with the Disk Cache new desk accessory. When the system
(usually an FST) goes to read a system block, the block is identified as a
candidate for caching and is cached if possible. Applications define blocks
as candidates for caching by using the cachePriority field of many class 1
GS/OS calls. Note that class 0 calls do not have this field, thus
applications using exclusively class 0 calls will not be able to cache any
application blocks.
Although this difference may seem like a limitation, it in fact improves
performance. On the Macintosh, most applications that work with files (like
database managers) leave the file with which they are working open while they
need it; the file is only closed when the window containing it is closed.
Apple II programs historically are quite different--they usually read an
entire file at the beginning, modify it in memory, and write it when the save
function is selected. A moment's thought will show that if GS/OS arbitrarily
cached most or all application blocks, system blocks that would be used again
(such as directory blocks) will be kicked out to make room for them. We will
see that this is probably a bad thing to do.
How to Cache Effectively
The first tendency of many programmers is to attempt to completely cache any
given file, but this usually leads to a degradation in performance, not an
improvement. In small caches such strategies can slow the system to a crawl,
and large caches offer no significant improvement. Remember that until the
cache memory is needed, it is available to the system. The cache size for
GS/OS as set by the user is the maximum to be allotted, not the minimum.
Suppose you are attempting to cache a 40K file (80 512-byte blocks). If the
cache is set to less than 40K, the entire cache will be written through,
kicking out all system blocks currently cached. A cache of this size slows
system performance for little gain, since the entire file could not be cached
anyway. Even if the cache is large enough to hold the entire file, you are
needlessly taking twice the amount of memory with the same file (by reading it
into memory you have obtained from the Memory Manager and by asking GS/OS to
keep a copy in the cache).
It is evident that the system makes the best use of the cache automatically,
freeing your application from the duty of caching system blocks, but there are
certain instances where caching application data can improve system
performance.
An application which does not limit document size to available memory will
often only keep a portion of the document in memory at any given time.
Suppose that the beginning of such an application's document file contains a
header which to various parts of the document file. (These parts could be
chapters for a word processor, report formats for a database manager, or
individual pictures for an animation program.) This document header is
probably not very long, but the application will likely need to read it quite
often to quickly access various portions of the document file.
This header is a prime candidate for caching since it is a part of the file
which will definitely be read many times during the life of the application.
Contrast this with arbitrarily caching the entire file, which needlessly
wastes both cache space and available memory to keep a duplicate copy of
something that may or may not be read from disk again.
Although caching provides enormous benefits to GS/OS, indiscriminate use of
the cache will waste memory and degrade overall system performance. Be
prudent and limit your use of the cache to those portions of your document
files which will be read from disk many times.
Further Reference
o GS/OS Reference, Volume 1