Knowledge Article View - Asistencia al cliente

Evaluating memory requirements for PROC OPTMODEL can be complex. Frequently PROC OPTMODEL storage requirements will be dominated by VAR, CON, and parameter array storage, with a single problem instance and no special suffixes. In this case, the expected memory requirements are summarized in the following table, assuming an LP or MILP solver. This table shows requirements on 32 and 64 bit platforms in bytes per element included in the problem.

For example, an element of a VAR array with two indices, say x[1,2] will take approximately 202 (186+8*2) bytes on a 32-bit platform. This value includes memory that is used to hold the element indices as well as many suffix values (such as x[1,2].ub), the suffixes stored with the PROBLEM instance, as well as data structures used during problem generation.

Storage Locations

User visible model data is stored in a variety of locations, depending on the processing requirements for the value. The most important locations used are the array element storage and the problem instance storage. Other less common suffixes are stored in a per element attribute list, as described in the table below. These element attributes are created only when needed, generally when the corresponding suffix for an array element is assigned a non-default value. An element attribute takes 24 bytes on 32-bit platforms and 32 bytes on 64-bit platforms.

Arrays, problem instances, and sets, as discussed in the sections below, use dynamically re-sized hash tables which have an overhead that depends on how full they are. Therefore, memory requirements can vary from the values given below. The memory requirements below include an overhead per element which corresponds to the expected hash table overhead.

User Declared Arrays

This table shows the approximate memory requirements in bytes for user declared array elements on 32-bit and 64-bit platforms. This does not include per symbol overhead.

As a special case, a NUM array element initialized to a floating point or missing value constant will not normally take any space unless it is specifically assigned a value. For example, in the following code array elements for 'c' will be created only when nonmissing values are read from the 'coeffs' data set.

proc optmodel;
set<str> ISET;
num c{ISET} init 0;
read data coeffs nomiss into ISET [i] c;
put (sum{i in ISET} c[i]);
quit;

As another special case, NUM, STR, and SET array elements with a single, simple numeric index (declared as either a set name or a range expression) can be stored with a compact vector form that takes 9 bytes per element. This form is used only for elements with integer indices >=1, and only if the elements are initialized in something close to sequential order.

proc optmodel;
set ISET init 1..100;
num c{ISET};
for {i in 1..100} c[i] = i; /* creates vector elements */
c[100] = 42; /* too big a jump, creates a hash element */
quit;

Problem Instance Elements

The following table describes approximate storage requirements in bytes per problem element included in a PROBLEM instance. Each instance that includes a problem element requires separate storage for instance data.

For example, a problem with 10,000 variables and 8,000 constraints would require (10000*48+8000*40)=800,000 bytes on a 32-bit platform.

The .BLOCK suffix values take 9 bytes. Values declared with SUFFIXES= clause also take 9 bytes. The total requirement for these suffix values for each element is rounded up to a multiple of 8 or 16 bytes (on 32-bit or 64-bit platforms respectively), so the minimum requirement is 16 bytes. The var.SOL[n] data take 8 bytes per stored solution, for each VAR element included in the solution.

Sets

Copying a set value does not create a new set, therefore set memory requirements depend on how much sharing of values occurs.

Note: A set representing a range expression (such as 1..1000) does NOT require storage for each member, only for the equivalent of 2 to 4 members (representing the start, limit, optional increment, and optional multiplier values). If a set is created by adding elements in an arithmetic regression, then a range set can be created automatically.

Note: Sets allocated during threaded problem generation use a private pool which starts with an initial allocation of around 1k bytes. Therefore small sets created during threading could have higher memory overhead than described below.

Strings

Strings stored in an array or used as an index are saved in a string table so only one copy is shared by all uses. String text is stored as bytes in the MVA session encoding. On a 32-bit platform a string requires approximately 32 bytes plus the space for text storage, rounded up to a multiple of 8. On a 64-bit platform this becomes approximately 52 bytes plus the space for text storage, rounded up to a multiple of 16.

Problem Generation

PROC OPTMODEL generates an initial problem description which is processed further, possibly presolved, before being passed to the solver. PROC OPTMODEL keeps one problem description in memory, except that an existing problem description is deleted at the end of initial problem generation to allow reuse of data. The problem generation overheads are shown in the following table. Requirements for nonlinear equations depend on the expanded form and other complex factors, so the sizes below are minimums.

The LP and MILP solvers require an additional 12 bytes per nonzero value to generate a column-wise copy of the constraint matrix. If the PROC OPTMODEL presolver is active then additional memory is needed for the presolved version of the problem.