Performance tips

Contains a checklist of modeling best practices.

Here is a check list for quick reference:

  • Use the profiler to detect execute blocks that run for a long time during the preprocessing phase. See Profiling the execution of a model in IDE Tutorials.

  • If you observe that the execution of a model is slow because the main scripting block loads many engine instances or submodels, you can improve this by turning off the OPL Language option Update charts and statistics in main. See OPL language options in IDE Reference.

  • In pre- or postprocessing script statements, do not initialize array elements to zero, OPL does that for you. See the note in Initializing arrays in the Language User’s Manual.

  • To initialize arrays, prefer generic indexed arrays rather than an execute INITIALIZE block. See As generic indexed arrays in the Language Reference Manual.

  • Avoid dummy formal parameters for tuple components. See Formal parameters in the Language Reference Manual.

  • Cache results for find() lookup.

  • Calculate iteration sets for conditional blocks.

  • Declare local script variables using the keyword var. See Declaration of script variables in the Language Reference Manual.

  • In CP models with customized search strategies, consider the order of search phases. See Multiple search phases in the Language User’s Manual.

  • Constraint labels may have a significant performance and memory cost. See Constraint labels in the Language Reference Manual.

  • To improve the performance of a model from the IDE, use the Tune Model button. See Using the performance tuning tool in IDE Tutorials.

  • Using sorted versus ordered sets affects the memory consumption and the speed of execution but the effect is different depending on what operations are carried out on the sets. It is therefore not possible to give general recommendations on when to use sorted sets rather than ordered sets.

  • Using slicing rather than if statements usually saves time and memory. For example, in the following code lines

    int n=1000; 

dvar int x[1..n][1..n];

subject to
{
    
ct1:forall(i in 1..n,j in 1..n:i==4 && j==5) x[i][j]==5;
ct2:forall(i in 1..n,j in 1..n) if (i==4) if (j==5) x[i][j]==5;

}

    the ct1 constraint is 60 times faster and lighter in memory than ct2.

To write efficient models, see also Modeling tips in the Language User’s Manual.

To control memory consumption. See Memory usage.