- 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
.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.