LP & QP Performance with v57

• 27 June 2026
• benchmarks,
• optimisation

With the release of ojAlgo v57.0.0 comes significant changes to both the LP and QP solvers, including improvements to the revised simplex and an entirely new ADMM QP solver alongside the existing active-set solver. Time to measure the results.

This is an update to the LP & QP Java Performance Report from November 2025, now with ojAlgo v57.0.0 and updated versions of the other solvers.

Solvers

• ojAlgo v57.0.0 (Open Source, Java, LP & QP)
• Hipparchus v4.0.3 (Open Source, Java, LP & QP)
• Clarabel v0.11.1 via Clarabel4j v3.2.2 (Open Source, native code accessed from Java, QP only)
• OR-Tools / GLOP v9.15.6755 (Open Source, native code, LP only)
• HiGHS v1.13.1 (Open Source, native code, LP & QP)

LP: Netlib 10k

The full Netlib LP collection with up to 10,000 variables or constraints — 97 models in total.

Execution time vs number of variables

Each dot represents one model-solver pair. The x-axis is the number of variables in the model and the y-axis is the execution time. Both axes are logarithmic. Each solver has its own colour with a trend line fitted to its results.

For smaller models (up to a few hundred variables) ojAlgo is comparable to OR-Tools and HiGHS. As models grow the native code solvers pull ahead, which is expected. ojAlgo and Hipparchus have roughly the same slope, but ojAlgo is positioned significantly lower — consistently faster. Hipparchus also fails on nearly half the models.

Execution time relative to OR-Tools

The x-axis is OR-Tools (GLOP) execution time and the y-axis is each other solver's execution time for the same model. Both axes are logarithmic. The dashed diagonal represents identical performance — points above are slower, points below are faster.

The HiGHS trend line sits close to the diagonal, confirming it performs similarly to GLOP overall. ojAlgo starts near the diagonal for smaller models but diverges upward as model size increases. Hipparchus, when it solves at all, is almost always the slowest — its trend line sits well above the others.

QP: Maros & Meszaros 10k

The Maros and Meszaros collection of convex QP problems with up to 10,000 variables — 48 models.

Execution time vs number of variables

Same layout as the LP chart: each dot is one model-solver pair with the number of variables on the x-axis and execution time on the y-axis. Both axes are logarithmic. Each solver has a colour-coded trend line.

For small problems (under ~100 variables) ojAlgo is often the fastest. As models grow, Clarabel scales best. ojAlgo and HiGHS are in a similar range for medium-sized models, with ojAlgo faster more often than not. Hipparchus solves about 58% of the models and has the steepest trend line, indicating the worst scaling.

Execution time relative to Clarabel

The x-axis is Clarabel execution time and the y-axis is each other solver's execution time for the same model. Both axes are logarithmic. The dashed diagonal represents identical performance.

ojAlgo is faster than Clarabel on roughly half the models they both solve, and slower on the other half — the two are genuinely competitive. HiGHS has fewer data points because it fails on 15% of the models, including several that both ojAlgo and Clarabel handle. Hipparchus is consistently above the other trend lines when it does produce a result.

Success Rates

Being fast is good, but being able to solve the model at all is more important. A solver that fails or times out on a model scores no time — it simply doesn't appear in the charts above.

ojAlgo solves 96 of 97 LP models and 46 of 48 QP models. For QP, ojAlgo has the highest success rate of all solvers tested — it is the only solver that can handle HUES-MOD and HUESTIS where all others fail.

Compared to v56

The LP solver has improved steadily since v56. Success rate on the full Netlib 10k set went from 88% to 99% — models that previously timed out now solve.

The bigger story is the new ADMM QP solver. It solves more models than both Clarabel and HiGHS. On the smallest models it is the absolute fastest choice, and it is faster than HiGHS on all but some of the very largest. Only Clarabel scales better on the big end, and Clarabel is native Rust code. For a solver implemented in 100% Java this is a remarkably strong result.

Methodology

The QP benchmark was run on a MacBook Air M4 and the LP benchmark on a MacBook Pro. The exact hardware shouldn't matter much — the charts show relative performance between solvers, not absolute speed numbers.

Each model-solver combination is evaluated repeatedly until consecutive execution times stabilise within 1%. The fastest stable time is recorded. If a solver fails to find a correct solution, times out, or crashes, no time is recorded and the pair is marked as FAILED.

All solvers are invoked via ojAlgo's ExpressionsBasedModel. The time measured corresponds only to the solver-specific code — model parsing and presolve are excluded.

The benchmark code and raw results:

• Benchmark code
• Raw results

• ← Previous
  ojAlgo v57