This function requires Analytica Enterprise or better.
Returns the memory, i.e., number of bytes, currently being used to store the mid and prob values of «variable».
This count may not be entirely accurate for several reasons, discussed below.
Portions of subarrays may be shared between different variables, or even within the same array. When you evaluate
MemoryInUseBy(X) + MemoryInUseBy(Y)
when a subarray is shared between
Y, the subarray will be double counted, since it will be counted in the result for both
Portions of subarrays may also be shared within the same array, and in some cases may be shared multiple times. Analytica utilizes this feature as a form of sparse-array representation, and in such cases the amount of memory consumed by the array may be dramatically smaller than a full dense array with the same number of cells would require. In Analytia 4.2 and earlier, MemoryInUseBy counts the amount of memory that a dense array of the given dimensionality would consume. In Analytica 4.3, MemoryInUseBy recognizes shared subarrays and tallies that space a single time, better reflecting the actual memory consumed.
The block of characters in a text value may be shared by identical text values. For example, if the text "hello world" appears in two cells, it is possible (but not guaranteed) that the same text block is shared by the two text values, so that the characters "hello world" appear only once in memory. This will generally be the case if the text originated from the same point in the model. However, Analytica 4.2 and earlier will count the space consumed by each text character without recognizing cases where the text is shared. In Analytica 4.3, MemoryInUseBy will recognize when the same text block is shared within the same array and avoid this double-counting.
Internal Heap Overhead
All memory allocations involve a certain amount of "heap overhead", which is space used by the underlying execution system to support dynamic memory allocation. Some of this overhead is consumed by the Windows operating system, some by the run-time system, and some by Analytica's own memory management subsystem. For example, if Analytica needs a block of 120 bytes, it will request 120 bytes. It is possible that the memory management system will reserve 128 bytes (hypothetically) to obtain various efficiencies, and then may add another 32 bytes of bookkeeping to keep track of what has been allocated, etc. The exact numbers vary with circumstances and are extremely hard to predict exactly. None of this overhead is counted by MemoryInUseBy.
Heaps are also subject to fragmentation, in which small blocks of unused memory may exist between active allocations. These drive up the actual amount of memory controlled by a process, even though they are not actively in use.
Local Index Space
The space used by local indexes is generally not tallied. If you ask for the space used by array
A, which happens to be indexed by a local index
A.I, the object
.I and its value consumes space which is not tallied. That same space will be shared between all arrays that use that local index.
There are also a few things that are not fully counted. Also, memory used internally by «LP», «QP» or «NLP» objects is not only partially counted (Analytica has no way of knowing exactly how much memory is being consumed internally by the Frontline Solver).
Intermediate Values during Evaluation
The result returned from MemoryInUseBy reflects the amount of memory used by the mid, prob and index values at the time it is called. When a result is computed, intermediate values may require more space than the final result alone, and in some cases when these intermediates have extra dimensions, this can be dramatically more space. The space temporarily utilized during computation is not measured by this function, and there is currently no method for accessing the maximum amount of memory consumed during a computation from within Analytica.
Determine amount of memory used to store results for Variable Revenue: