Geometry Caching and the Global Cache Manager

Home > User Guide > Memory Management

Geometry Caching and the Global Cache Manager

A global cache manager controls a list of cache objects that are made available to spline curves and surfaces as needed. This change can reduce model memory requirements with on average a negligible penalty in performance. The number of cache values and objects to retain is fully configurable. The global cache manager can also be run in a mode which essentially retains the behavior of prior versions of ACIS if performance becomes a concern.

Geometry Caching

The ACIS product employs a caching mechanism to improve the performance of geometric calculations involving interpolated curves and spline surfaces. Results of computations are stored so that subsequent calls to the same functions with the same arguments can simply retrieve the values from memory rather than recalculate them. The resulting boost in performance can be considerable with reductions in compute time of up to 50%.

The cache for spline surfaces ( spl_sur class) actually consists of three separate caching mechanisms, one each for:

evaluations
calls to point_perp()
calls to param()

The cache for interpolating curves ( int_cur class) is similar except that an additional mechanism exists for calls to closest_point().

Global Cache Manager

The global cache manager (gcmgr) maintains the list of active cache objects for the int_cur and spl_sur classes. The gcmgr runs in one of two modes: the default "hard limit" mode or the optional "no limit" mode.

In the "hard limit" mode, the number of cache objects maintained at any given time is not allowed to exceed a fixed value. This limit is enforced by recycling the cache objects that have not been accessed for the longest time. The underlying assumption is that the cache is most valuable in situations where operations are performed on the same region in the model in rapid succession.

In the "no limit" mode each cache object persists for the life of the associated curve or surface. This mode is useful when performance is paramount and memory consumption is not a concern. The "no limit" mode also has less overhead than the "hard limit" mode with a very large cache list size, because the "hard limit" mode attempts to optimize cache objects to retain and those to recycle.

Adjusting the Global Cache Manager Settings

General Considerations

Changing the settings of the gcmgr has an impact on memory use that is straightforward to anticipate, but the effect on performance can be more difficult to predict. The reason is that caching can at times enhance and at other times degrade performance. A cache is considered effective if stored values are frequently retrieved during cache lookups. A high level of such cache hits can significantly reduce computation times for the modeler. On the other hand, if cache lookups have many misses and few hits, then the overhead of searching through the cache can lead to an overall slowdown of the modeler.

The effectiveness of the ACIS caches varies depending on the model and type of operation performed. In general, in cases where the cache is effective, performance improves when more values are stored in cache, but the gain comes at the cost of increased memory use. In contrast, in instances where the cache is ineffective, increasing the cache size may actually cause performance to suffer.

Tuning the Caching System

ACIS has two methods for tuning the caching system:

Change the maximum size of the lists maintained by the global cache manager.
Change the maximum number of entries for each cache mechanism.

The default values have been selected to work well over a wide range of models as determined by internal testing. Specialized applications may benefit from alternate settings.

Increasing the maximum number of entries for a given cache mechanism is directly related to performance degradation for ineffective caches, because longer lists lead to longer search times for cache misses. In contrast, increasing the size of the list of cache objects maintained by the gcmgr only indirectly degrades performance for ineffective caches. Note that the overhead for the gcmgr is essentially constant and does not vary with the size of its list of cache objects. However, performance can still suffer because it is better to recycle ineffective caches rather than maintain them for unsuccessful lookups.

To change the the settings for the "hard limit" mode, use:

the scheme commands (iccache:set-size) and (sscache:set-size), or
the corresponding global C++ functions set_ic_global_cache_size() and set_ss_global_cache_size().

To change to the "no limit" mode, use:

the scheme commands (iccache:set-mode) and (sscache:set-mode), or
the global C++ functions set_ic_global_cache_run_mode() and set_ss_global_cache_run_mode().

The number of entries in each cache is configurable by setting the options "iccache_eval#_len", iccache_perp#_len, "sscache_perp#_len", and so on. By default, the evaluation caches are set to a size of 16 entries and the remaining caches allow 8 entries. Setting all of these options to zero prohibits any results from being stored and effectively turns off the caching mechanism.

To get the current state of the caches, use the cache:stats scheme command and the global functions get_ic_global_cache_statistics() and get_ss_global_cache_statistics().

[Top]

© 1989-2007 Spatial Corp., a Dassault Systèmes company. All rights reserved.