Performance issues with DPP problems

[kmonson]

Describe the bug
When I replace parameters with constants to make the problem DPP the solver takes dramatically longer for larger problems the moment the problem becomes DPP.

To Reproduce
Data files and code to reproduce this can be found here https://github.com/kmonson/cvxpy-performance.

git clone https://github.com/kmonson/cvxpy-performance
cd cvxpy-performance
pip install -r requirements.txt
./test.sh

This will run the non-dpp then dpp versions of the same problem at multiple problem sizes.

Expected behavior
Problem compilation and solving should take roughly the same amount of time for both DPP and non-DPP problems for the first solve.

Version

• OS: OSX
• CVXPY Version: 1.1.0 or greater.

[kmonson]

I should add that removing constraints loop here https://github.com/kmonson/cvxpy-performance/blob/master/solver_dpp.py#L136 is not all of the problem and while I can refactor it some I can't really eliminate it. Besides, it compiles quickly if the problem is not DPP.

[akshayka]

This is a know issue. DPP compilation will likely never be as fast as non-DPP compilation -- the first compilation of a parametrized program performs significantly more work, to dramatically speed up subsequent compilations.

That said the overhead is much larger than we would like. We would like to fix this, but it is a substantial engineering effort and not currently on our near-term roadmap.

For now, DPP may help for some problems with a few parameters (say hundreds or a few thousand), for which you can pay the overhead of the first compilation and for which you really need subsequent solves to be fast. In cases where the overhead is prohibitive, you can replace parameters with constants.

[kmonson]

OK, that is what I was afraid of. I'm writing up a feature request to hopefully help with this problem.

[kmonson]

Is there a way I can easily tell cvxpy to not treat the problem as DPP even if it is?

My program runs one large problem (8760 hours long) or 365 24 hour long problems or something in between depending on the user needs. From my benchmarking there is a pretty clear line at which it's beneficial to purposefully switch off DPP. It would nice if I could do this without modifying how the problem is built based on user parameters.

[sjschneider]

I am also encountering issues with overhead and DPP compilation. There are many circumstances where I want to use Parameters, but not pay the overhead associated with DPP compilation. Rewriting code to replace the parameters with constants would be troublesome and I think the logic should exist within cvxpy to disable DPP, perhaps converting parameters to constants during problem formation. What would it take to add a flag for this?

[akshayka]

@kmonson , @sjschneider : this is a reasonable request. We have plans to decrease the overhead of DPP compilation, but these plans are not on our near-term roadmap. Having a flag that disables parametrized compilation in the meantime is, I think, perfectly reasonable.

We will look into adding something like this, and will give an update on this thread once we have a design.

[rileyjmurray]

@kmonson @sjschneider, for the time being you can do something like

scale = cp.Parameter(shape=(1,), value=1.0)
prob = cp.Problem(scale**2 * objective, constraints)

If you make that change then the problem is no longer DPP (no longer affine in Parameter objects) so parameters will be evaluated before canonicalization. This is just a quick hack though and might not help as much as a proper fix.

[kmonson]

Thanks @akshayka @rileyjmurray.

I opened a ticket for this: #1340

I ended up with this solution. I don't know if it's any better or worse.

        if not self.use_dpp:
            # Inject a nonsense constraint to make the problem non DPP
            constraints.append(
                cvxpy.Parameter(value=0) * cvxpy.Parameter(value=0) >= 0
            )

[rileyjmurray]

Follow-up: we just resolved GitHub Issue #1340 with PR #1669. I'll leave this issue open since technically "performance issues with DPP problems" isn't resolved.