Imagix 4D User Guide

Project Resources

To load the results of data collection and to perform its analysis functions, Imagix 4D uses a series of databases. Some of these are loaded on demand when the particular analysis is requested. For fastest performance, Imagix 4D loads the databases into memory. Optionally, some of the databases can be managed in disk storage in order to avoid memory overflow when analyzing very large programs. The use of disk storage to extend database resources typically comes at the expense of speed and can result in several factors (2 to 20) of slowdown.

This tradeoff of memory and speed is controlled through a setting in the Options dialog (File > Options... > Data Collection > Project Location and Resources), with more precise control available through the 4Ddefaults file (see the file ../imagix/user/sample.4Ddefaults for details). The tradeoff persists through an Imagix 4D session; for a setting change to take effect, you'll need to change the setting, then close and reopen Imagix 4D.

Core entity and relationship information is always kept in memory. This information forms the basis of most of the Imagix 4D analysis and resulting displays, including file, class, and function graphs, cross reference information, and source browsing. Memory requirements for the core data are dependent on the number and uses of symbols (entities) in your code. Typically, source code containing up to 4-10 million statements can be handled in a single project by the 32-bit version of Imagix 4D. If Imagix 4D runs out of memory on the initial project load, one approach for reducing the size of the core data is turn off the collection of information about local variables. Doing so will restrict some of the analysis that can be performed; in particular, several of the flow check reports require local variable data. A second approach for reducing memory requirements is split your source code, creating separate projects that can be independently analyzed.

Metrics and source check information is kept in a second database. Unlike core data, metrics data is loaded on demand. By default, the resulting metrics database is loaded in memory. Being demand driven, the data size depends on what metrics are requested; as a general approximation, the data size can be assumed to be 1-2 times the size of the core data. This means that source code up to 1-5 million statements can be handled in a single project by the 32-bit version of Imagix 4D. Memory requirements can be reduced through the Project Resource settings. With a setting of `Large' or `Very Large', projects containing up to 3-8 million statements are possible. This reduction is achieved by using a disk database; using disk rather than memory results in a slowdown of 2-10 times in the initial calculation of metrics data. With the `Very Large' setting, this is a one-time slowdown for a given project; the second time metric information is loaded for a project, the load time is actually faster than from memory, because the metrics have already been calculated from the raw data.

Dataflow data used for flow check reports and calculation trees is kept in a third database. Like metrics data, dataflow data is loaded and calculated on demand. The underlying global dataflow analysis is very complex, and requires considerable time and memory. The size of the dataflow data ranges between 5 and 20 times that of core data, depending on such factors such as number of non-local variables, number of functions and recursions, and cyclomatic complexity. This means projects can handle source code containing 0.2-1 million statements in the 32-bit version of Imagix 4D under the default configuration, where memory is used intensively. Projects of those sizes can take hours to analyze. A setting of `Large' or `Very Large' can slow down analysis by a factor of 5-20 but increase possible project sizes to 1-5 million statements. Note that for projects of these sizes, the analysis can take tens of hours.

Larger projects can be supported by running the 64-bit version of Imagix 4D, available for Windows and Linux. The 64-bit version uses twice as much memory for the same project, but by avoiding the memory limit of a 32-bit application is able to support larger projects. For example, to do basic analysis of the 4-10 million statement project mentioned above, the 64-bit version of Imagix 4D would require a 4GB of memory, twice what's available on a 32-bit system. Increasing the system size to 8GB would be enable projects containing nearly 8-20 million statements. However, with the larger projects, performance loading, analyzing and viewing data would start to suffer.