Previous: Keyed Files and PDisplay
Up: Keyed Files and PDisplay
Next: Storage of port images for Layout messages
Previous Page: Keyed Files and PDisplay
Next Page: Storage of port images for Layout messages
The Keyed File unit, on which PDisplay is built, keeps an internal directory of the names of all the messages in the (single) keyed file open at a given time, keeping with each its location and number of items in the pool of text that constitutes the ``mulched'' keyed file's body.
The p-System version of Keyed Files holds a single 512-byte block of that directory in memory, thereby implementing a window on the directory. As the keyed file grows, and more messages must be referred to, the directory in the file grows correspondingly, and during its use by its owning dialogue, different blocks of directory must be swapped into memory as Keyed Files finds that message names requested by its clients cannot be found in the resident directory block.
Since Keyed Files also holds in memory a user-specified number of blocks of ``window'' on the text pool, which must be reloaded from disc as the usage of the file progresses, there are times when both directory blocks and text pool blocks are being replaced from disc.
Under the p-System the performance has been acceptable, probably due in part to the p-System's sequentially allocated file system, even though it's probable that a given directory block could be re-read several times over in the course of a dialogue. However, attempting to retain this implementation under DOS caused delays and hesitations in the runtime performance of keyed files, often at unacceptable locations in the presentation.
It was therefore necessary to replace the single directory block with a search structure that could be initialised with the entire directory contents at once, so that no part of the directory need be re-read. For the sake of a rapid implementation, and because the directory contents never change after their initialisation, a binary search tree structure was chosen. However, although the nature of the message names in the Scientific Reasoning Series' dialogues have no particular order, and are therefore reasonably likely to produce at least somewhat balanced search trees, this is clearly not an optimal choice for keyed files in general. Keyed files produced by other approaches to dialogue impelementation might easily yield names lying roughly in order, in which case the tree would unbalance to nearly linear search. Updating to a more robust searching structure when time becomes available to do so is therefore recommended.