If you write your own constraint (rather than exploiting predefined constraints from Solver), you also need to think about the granularity of propagation in your application. In other words, you must define the hooks between constraints and events that modify variables. If you hook onto only the value event, you may miss out on certain propagations; in contrast, if you hook onto every modification with the domain event, you'll invoke the constraint so frequently that you'll benefit little if at all from domain reductions, thus penalizing the global resolution time.

Whether you are using predefined Solver constraints or writing your own, you can also choose the granularity of the solution search. In the algorithms that Solver uses, you can decide how to split up the search space at the level of the chosen variable. The standard choice IloInstantiate works on the minimal bound of the chosen variable; IloDichotomize works on the median (average) value of the chosen variable.

Your choice about this issue should be guided by experimentation; in other words, you should try more than one strategy and measure the results. The reason that experimentation is so important for this issue is that the best choice depends on information propagated as a function of events.

For example, when most of the constraints are arithmetic and are consequently propagated on the event range, binary generation using IloDichotomize is usually the most efficient.

In contrast, if most of the constraints propagate only on value events, it's a better idea to generate the values of the variables.