In this section we cover several guidelines 
on how to use CHR to write constraint solvers and how to do so 
efficiently.
- Check guard bindings yourself
 It is considered bad practice to write guards that bind variables of the 
head and to rely on the system to detect this at runtime. It is 
inefficient and obscures the working of the program.
 
- Set semantics
 The CHR system allows the presence of identical constraints, i.e. 
multiple constraints with the same functor, arity and arguments. For 
most constraint solvers, this is not desirable: it affects efficiency 
and possibly termination. Hence appropriate simpagation rules should be 
added of the form: [ constraint\constraint <=> true ]
 
- Multi-headed rules
 Multi-headed rules are executed more efficiently when the constraints 
share one or more variables.
 
- Mode and type declarations
 Provide mode and type declarations to get more efficient program 
execution. Make sure to disable debug (-nodebug) and enable optimization 
(-O).
 
- Compile once, run many times
 Does consulting your CHR program take a long time in SWI-Prolog? 
Probably it takes the CHR compiler a long time to compile the CHR rules 
into Prolog code. When you disable optimizations the CHR compiler will 
be a lot quicker, but you may lose performance. Alternatively, you can 
just use SWI-Prolog's
qcompile/1 
to generate a.qlffile once from your.plfile. This.qlfcontains the generated 
code of the CHR compiler (be it in a binary format). When you consult 
the.qlffile, the CHR compiler is not invoked and 
consultation is much faster.
 
- Finding Constraints
 The find_chr_constraint/1 
predicate is fairly expensive. Avoid it, if possible. If you must use 
it, try to use it with an instantiated top-level constraint symbol.