Efficent modeling with BCL

This section discusses some recommendations for the efficient use of BCL. Such considerations are particularly important when working with large-size optimization problems or when solving a large number of models / model instances in a single application. Our criteria for measuring efficiency are:

• model execution speed
• memory consumption

Please note that this section is only concerned with modeling aspects. For issues relating to the solving process, such as the performance of the underlying optimization algorithms, the reader is refered to the Xpress Optimizer Reference Manual.

Names dictionaries

BCL works with two names dictionaries, the main names dictionary (storing the names of constraints, decision variables, etc.) and a dedicated dictionary for index set elements. The former is active by default wheras the latter gets activated only if a model uses index sets. The following remarks refer principally to the names dictionary.

Disabling the names dictionary

If an application does not make use of the names of modeling objects the names dictionary can be disabled to save memory. The function XPRBsetdictionarysize for resetting the dictionary size can only be called immediately after the creation of the corresponding problem. Once the dictionary has been disabled it cannot be enabled any more. All methods relative to the names cannot be used if this dictionary has been disabled and BCL will not generate any unique names at the creation of model objects.

• C:  XPRBsetdictionarysize(prob, XPRB_DICT_NAMES, 0);
• C++:  XPRBprob.setDictionarySize(XPRB_DICT_NAMES, 0);
• Java:  XPRBprob.setDictionarySize(XPRB.DICT_NAMES, 0);
• C#:  XPRBprob.setDictionarySize(BCLconstant.DICT_NAMES, 0);

Setting the names dictionary size

If you wish to use the names dictionary we recommend to choose a size close to the number of variables+constraints in your problem, preferrably a prime number. (Too small values will slow down access to the names dictionary, larger values imply higher memory usage.)

Handling of problems

Resetting a problem

You should reset a problem to free up memory if the solution information is no longer required (function XPRBresetprob). Resetting a problem deletes any solution information stored in BCL; it also deletes the corresponding Xpress Optimizer problem and removes any auxiliary files that may have been created by optimization runs.

• C:  XPRBresetprob(prob);
• C++/Java/C#:  XPRBprob.reset();

Other functions for freeing memory of auxiliary/intermediate structures: XPRBcleardir, XPRBdelarrvar, XPRBdelbasis, XPRBdelcut

Releasing a problem

With C a problem may be deleted explicictly (XPRBdelprob) to free up all memory used by it. In the object-oriented interfaces make sure to release all references to a problem to enable garbage collection on the object.

The Java interface also publishes the problem finalizer: XPRBprob.finalize().

Constraint definition

Object-oriented interfaces

Overloaded operators and the more algebraic-style definition of constraints via expressions in the object-oriented interfaces of BCL lead to more easily human-readable models but unfortunately, they also create many intermediate objects, making them computationally less efficient. With constraint/expression sizes upwards of 1000 terms a slowdown tends to become noticeable and alternative ways of constraint formulation should be sought.

The best alternative is to use the addTerm and setTerm methods for constraints or expressions (these avoid the creation of intermediate objects, such as terms or expressions, thus reducing memory consumption and most often leading to a speed up).

Example:

• C++:
  Replace
    ctr += 17*x;
  by
    ctr.addTerm(17, x);
• Java:
  Replace
    ctr.add(x.mul(17));
  by
    ctr.addTerm(x, 17); // or: ctr.addTerm(17, x);

Order of enumeration

In pre-Release 2008 versions of BCL it is recomended to enumerate / access decision variables within loops in the order of their creation. This recommendation does not apply to BCL 4.0 and newer.