Memory management

Image processing applications normally have a relatively high demand for memory, depending on the number of cameras used, image size and complexity. Viper.NET contains some mechanisms to reduce the memory consumption or to enable an efficient handling of memory.

See also
Enhanced

Max. TgItems in Memory

In Viper.NET, theoretically any number of image-sources, jobs and ToolGroup Items can be created. However, with each object, the memory requirements of the application also increase. For this reason, CogToolGroups that are not used for a longer period of time and that are the basis of ToolGroup Items can be unloaded automatically. The global-settings specifies the maximum number of ToolGroup Items that can be in memory at any one time. If a currently unloaded ToolGroup item is to be executed, the “oldest” ToolGropus in memory is unloaded first, the requested ToolGroup is loaded and then executed.

Warning

Loading/unloading ToolGroups takes time, which must be included in the first trigger.

An alternative to many ToolGroup items loaded in parallel is provided by the type management. If only small parts in the BV process differ, e.g. the patterns of a CogPMAlignTool, the ToolBlockSelectorTool can also be a useful alternative.

But when does which option make sense? This question cannot be answered in a general way and depends on the characteristics of the application:

  • High type diversity, plant is operated “type-clean” -> type management

  • Different processes for the same type, manageable type variety -> several ToolGroup items

  • Minor differences between product variants -> ToolBlockSelectorTool

garbage collection

The .NET runtime environment on which Viper.NET is based has an automatic memory management (garbage collection). From time to time, the memory must be examined by the garbage collector and memory that is no longer needed must be freed. Normally, garbage collection is performed automatically by the system when memory is needed and the opportunity seems “favorable”.

Depending on the size of the application, this process has a negative impact on the runtime of the image processing jobs. Therefore, in Viper.NET an explicit garbage collection can be triggered after N jobs. The configuration is done in the global-settings.

Hint

It is recommended to set N to the number of configured jobs.

Display/log memory consumption

The current memory usage can be displayed for analysis in the header and cyclically written to the log file. Both are enabled in the global-settings.