calculation cache

The GeoDMS keeps the calculations it performs in a calculation cache, with one entry per distinct calculation. When the same calculation occurs more than once, in several items or several times in one calculation rule, all occurrences use that one entry, and so share one calculation and its result.

what counts as the same calculation

An entry is identified by the calculation itself: the operator and its arguments, with each item reference replaced by what that item stands for. That is the item’s own calculation rule or, for an item without one such as source data read from a storage, the item itself. Item names, and the place where a calculation rule is written, play no part. So:

  • two items with the same calculation rule share one result;
  • an item whose rule only refers to another item, such as c := a, shares the result of a;
  • a Subexpression that occurs in several calculation rules, or more than once in one rule, is calculated once, also when no item names it;
  • the same text can stand for different calculations: x * 2 in two containers that each hold an item x is two calculations, unless those two items have the same calculation themselves;
  • arguments are not reordered: a * 1.5 and 1.5 * a are two entries.

In

unit<uint32> d: nrofrows = 1000;
attribute<float64> a (d) := float64(id(d)) * 1.5;
attribute<float64> b (d) := float64(id(d)) * 1.5;
attribute<float64> e (d) := 1.5 * float64(id(d));
parameter<float64> s     := sum(float64(id(d)) * 1.5);

a, b and the argument of sum are one multiplication; e is a second one, which reads the same float64(id(d)).

how long a result is kept

A result stays in memory as long as something still needs it: an item that is yet to be calculated from it, an open view that shows it, or an item named on a GeoDMSRun command line, until GeoDMSRun has processed that item. When nothing needs it any more, its data is released, and a later request calculates it again. To keep the data of an item once it has been calculated, set its KeepData property to True. Results smaller than 128 bytes, such as a numeric Parameter, are kept anyway.

A result that is tile pipelined with tiles produced on demand, such as that of Mapping, releases each tile when its consumer is done with it; a tile that is asked for again is calculated again.

The cache exists only in memory, for as long as the configuration is loaded, so a new session calculates again whatever it is asked for. To reuse results between sessions, write them to a storage, see Strategic decoupling.

sharing a step on purpose

Only whole calculations are entries; what an operator does internally is not. Two classifications of the same data in the two argument form of the Classify functions, ClassifyJenksFisher(District/NrInh, classes) and ClassifyEqualCount(District/NrInh, classes), are two different calculations, and each builds its own value-count table of District/NrInh. The three argument form reads that table from a weeded_counts result instead, which makes the table a calculation of its own that both can share:

unit<uint32>         district_counts := weeded_counts(District/NrInh);
unit<uint8>          classes         : nrofrows = 4;
attribute<nrPersons> jf_breaks (classes) := ClassifyJenksFisher(district_counts/Values, district_counts/count, classes);
attribute<nrPersons> ec_breaks (classes) := ClassifyEqualCount(district_counts/Values, district_counts/count, classes);

The table is then calculated once when both break attributes are calculated together, for instance in one view. When they are requested one after the other, set KeepData on district_counts to keep the table in between.

see also