Disc caching works by storing large chunks of frequently used files in free memory, so that when an application tries to access a particular file, the operating system can refer to the copy kept in RAM rather than tell the hard disc (or some other storage media) to locate the file. It's considerably faster to read from and write to memory than access a hard disc, so therefore performance is increased. The operating system has to ensure that at some point the data in memory is written back to the disc for safe keeping. This caching operation is transparent to the user and application software, as they are not aware of these internal optimisations being performed by the operating system.ADFS already employs a set of buffers but they reportedly work in a limited fashion. Dominic's module uses a 16M cache with read-ahead and write-through features. This means the cache makes an educated guess as to which data the user is going to access next and preempts this by copying the files to memory beforehand. Write-through works by writing data directly to disc as well as the cache, minimising the amount of data lost if the computer were to suddenly crash or lose power. This sacrifices a potential performance boost to writing operations, though.
Dominic said, "The cache works by sitting between Filecore, the part of RISC OS that knows what to read and write to discs, and the low-level device drivers: ADFS, SCSIFS, and IDEFS, which know how to drive specific pieces of equipment. Calls to the low level drivers to read or write a block from the disc are intercepted, and if the information is in the cache, the cache is used instead of the disc. It's actually fairly simple."
With the disc cache module enabled, seconds are shaved off building projects with the Castle C++ compiler and applications including !PDF are "smoother" to use. Dominic added, "I'll be including a little benchmark suite - nothing too scientific yet - with the test suite to see what sort of improvements in speed are noted on different hardware sets. I've not done too much in the way of benchmarking yet though as I'm more interested in getting it bulletproof stable and then speeding things up."
The software is not Iyonix compatible, however, because of its low level nature and a lack of a machine to test it on. He hopes to in the future improve the read-ahead algorithm and enable write-behind buffering to that data sent to a hard disc is grouped together to boost performance. The buffer cache could also expand and shrink intelligently according to how much free memory is available in the system, and Dominic says the algorithm that decides what stays in the cache could be improved. Support could also be added for CDFS and non-Filecore devices, and correct handling of removable media.
To alpha test Dominic's work, see the link below. He's currently considering whether or not to open source the module, or charge cash for it, depending on how well received it is and if he can get it to work for the Iyonix and A9.
Links
Dominic's disc cache announcement