4.9 Memory Management and Disk I/O

Memory Management as Sets are Resized

Although Aspen SCM Expert System tries to run entirely in memory, its memory management may sometimes cause substantial amounts of disk I/O which slows execution. By default all sets and tables have the PAGETYPE attribute permanent rather than transient. This means that memory for them is allocated when the case is loaded. You can see how much memory has been allocated by typing the command CHECK MEMORY.

For each set there is an actual count of the number of elements (attribute COUNT) and a maximum count (attribute MAXCT). The amount of memory allocated for each table is determined by the MAXCTs of the row and column sets. When the MAXCT of one of these sets increases, fresh memory is grabbed for the set and for all the tables indexed by the set. Values are then transferred from the old to the new memory and the old memory is released. Where the physical memory on the machine is exhausted, this process may require paging, i.e. disk I/O.

Increase MAXCT for Sets Explicitly

Problems arise where a set has reached its MAXCT and the set is being increased in size by APPEND. This adds a single element to the set and increases MAXCT by 10 (not by 1000 as the Help suggests). Such a process, if repeated, leads to massive requests for memory, and therefore disk I/O, which can dominate execution time. Note that this applies even where the tables affected are temporary ones which are not stored as part of the .CAS file.

The solution to this problem is to manage sets using a rule which is based on APPEND but which increases MAXCT in chunks rather than by 10 each time that COUNT reaches MAXCT.

A similar issue affects sets which are being edited, e.g. rules. If a set has reached its MAXCT the effect of adding another line in the editor is to increase MAXCT by 1. This requires new memory to be allocated for the set and the entire set to be copied to the new memory. Although this takes negligible time when compared to the time spent typing, it leads to a proliferation of old versions of the set. As such sets are usually permanent, they are stored in the case. Thus the proliferation of versions leads to growth in the size of the .CAS file and must be countered by periodic compresssion of the .CAS file. The need for this can be reduced by manually increasing MAXCT in chunks (although some edit operations appear to reduce MAXCT to equal COUNT, thus vitiating this procedure).


Back                                Table of Contents
Comments