[jwesthues]

"Constraint" means something different to Cassowary than it does to us here, and isn't obviously useful. An optimized matrix library (Eigen, BLAS, LAPACK, etc.) would provide a modest speedup without too much work.

So yeah, the constraints in SolveSpace are nonlinear. They're solved by a Newton-ish method, which for underconstrained sketches also minimizes at each step the sum of the squares of the distances that any un-dragged points move (plus some other stuff). The Jacobian matrix is computed by an internal symbolic algebra system, allowing considerable flexibility in the range of user-facing constraints without a combinatorial explosion of hand-coded special cases.

As whitequark notes, the final solution of the constraint equations is a relatively small part of the overall work. The difficulty is mostly in writing them, to handle many useful cases in relatively few lines of code, and to converge reasonably in the Newton's method.

For a dramatic speedup, we could partition the constraint equations into roughly-triangular form, and then solve sub-systems in dependency order. Practical sketches seem to have a lot of such structure, and a visualization of that graph would be an interesting expression of the design intent. (To be clear, this isn't a spreadsheet; you still have to numerically solve systems of multiple equations, just not all of your equations at once.) I wrote an earlier solver that did this in some cases, but SolveSpace doesn't at all.