KCMS CMM Developer's Guide

Optimization

Transformation optimization includes one or more compositions, but this is not always the case. That is why optimize() is separate from composition. Generally stated, optimizing an object makes it smaller, faster, more precise, or some combination of the above. It is up to the derivative to figure out what is best for its situation. For example, if your derivative contains a resource such as extra tables for quality purposes and the derivative is requested to optimize for space and speed, it may very well throw away those extra tables.

During a save, this same derivative may not want to get rid of these extra tables. Instead, it either can use the hierarchical method described in save or reread the tables back into memory and save them again. It is up to the derivative. The choice might depend on the size of the table or some error constraint on the transform. See "KcsXformSeq Derivatives" for information on how a derivative always composes and keeps that transformation for evaluation. Also note that it keeps the original transformations in the list unless it is also told to optimize for size, after which it will get rid of them.

If your derivative discards a resource in the process of optimizing and subsequently attempts to retrieve it, that resource may no longer be available. Ultimately it is up to the derivative to decide when and how to make that determination. It may (and probably will) change between releases of that derivative as well.

Optimization must be defined by the derivative if that functionality is needed. Only the derivative instances understand how best to optimize. The derivative can refuse any optimization request. It also can prioritize the types of optimization if more than one bit is set. For example, if the instance is told to optimize for space and speed and speed means to add space, then if you consider it appropriate, have your derivative add the space to support the speed increase.