Any limitations of using the interface in comparison to using the solvers directly?

[sandeep026]

Dear developers,

The unified interface is super easy to use when same problem can be solvers with different solver without modifying the code much. Does this come at a cost? Like are there any overheads introduced in the process?

[stephane-caron]

qpsolvers converts matrices and vectors from a single API to the APIs of the underlying solvers, so there is necessarily some computation time spent (1) converting from the qpsolvers API to the underlying solver API, and (2) converting back results from the solver API to the qpsolvers API.

You can check in the code how this is done for each solver interface. The number of conversion operations will be different for each solver (the most involved one may be ECOS, due to the SOCP-QP conversion), but it mainly consists in stacking matrices and vectors. For many QPs that time will be negligible compared to the solve time, but one should check this for their particular QP.

[stephane-caron]

One feature that could help with this decision (staying with qpsolvers or optimizing the matrix build time, e.g. by writing QP matrices directly in the format required by a specific solver) would be an option to measure conversion and solve times. Those could then be reported in the qpsolvers.Solution, and the measurements could be triggered by a new clock_timings: bool parameter.

I won't have the bandwidth to work on such a feature in the near future, but if someone opens a PR for it I can help review and integrate it into the project.