Performance: runtime growth
•Cubic in number of variables at a program point
–Linear in number of invariants checked/discovered
•Linear in number of samples (test suite size)
•Linear in number of instrumented program points
Potentially cubic.  But the number of variables at a program point is generally small.  Cubic in number of variables really means linear in number of invariants checked; and it really means linear in number of invariants discovered, since invariants which are falsified tend to be falsified early, and only a few invariants are checked for each

Each instrumented program point is processed independently.  The choice of program points examined is made by the front end.  The program points currently examined are procedure entries, exits, and in some cases loop heads.  User can suppress arbitrary classes, functions, etc.  [but can’t add arbitrary new instrumentation points].

The point of this is to let the programmer estimate runtime based on factors under his or her control.
The claims of this slide are supported both algorithmically (by the structure of the code) and experimentally (by a set of experiments).

For test suite size, the O(n) constant is small.

“A few minutes”:  10,000 samples for 70 variables.
In its current incarnation, the implementation is slow but usable.  There are a number of reasons to believe that it will get substantially faster.  (Omit the specific mention of absolute runtime?)