Performance issues about Z3 for Java

Question

I am running into some performance issues in my current project with Z3 for Java: Basically most of my current constraints are pretty simple: e.g: (f(x) = 2 && f(y) <= 3) || f(x) <=5

1. I am using static context and solver instances shared by the whole project:

   public class ConstraintManager {
       static Context ctx;
       static Solver solver;
       ...
   }
   

If I generate expr by the same instance of ctx for billions of times, is that going to an issue? When is the best time to invoke ctx.Dispose(), or, what's the best way to manage ctx?

1. I invoked expr.Simplify() to simplify some constraints like: f(x)=3 && f(x)<=2. But this API turned out to be very slow. Especially the length of constraint increased. Is this a known issue or is that because I used it incorrectly?

2. I am using expr.substitute(expr1, expr2), but I notice that z3 will turn the expr into a let-binding form after substitution. Is this for making the formula more compact?

Answer 1

1. Simplify performs simple algebraic simplifications. You can control its behavior in some cases. For example * distributes over +, but this can cause real overhead and one can turn off simplifications of this kind. Use z3 -pm:simplify from the command-line to inspect parameters. (on the other hand, Z3 will unlikely be able to solve the formulas where this simplification is too expensive).
2. The "let-bindings" are supplied by the printer. Internally, terms are represented as directed acyclic graphs where nodes are shared. Printing a DAG as a tree can be extremely expensive (exponential in the worst case). So the printer introduces let expressions when it determines that this gives a shorter print-length.

The .NET and Java APIs use the garbage collector to manage lifetimes of terms. They get recycled at the discretion of the GC. For top performance you can manage reference counts on your own, but then you have to bypass the supported API. The released source code contains the JNI/pinvoke relevant to do this. Note that rolling your own low level API is a lot of work and the low level reference counting is also not as easy to program with as the supported API.