0

The lpSolveAPI package in R lets you specify and solve a linear program. However calling solve() on an already solved LP is significantly slower than solving the LP to begin with. Why does this happen, and how can this problem be avoided?

Here is a minimal example showing the problem:

set.seed(42)

library(lpSolveAPI)


#------------
# Set up LP
#------------

m <- 2 ** 15

lps.model <- make.lp(nrow = m, ncol = 3)

set.column(lps.model, 1, rep(1,m))
set.column(lps.model, 2, rep(1,m))
set.column(lps.model, 3, rep(-1,m))

set.rhs(lps.model, rnorm(m) + rep(5,m))

set.objfn(lps.model,c(1,0,0))

set.constr.type(lps.model, rep(">=",m))


#-----------------
# Solve it twice
#-----------------


system.time(solve(lps.model)) # 0.02 elapsed

system.time(solve(lps.model)) # 0.14 elapsed

Why does it matter?

I am doing some sequential statistical tests; each test involves solving an LP, and each LP differs from the last in only O(log m) constraints. In theory it should be possible to do this very quickly by solving the first LP and saving the solution, editing the constraints slightly, then using the solution as a warm start for the next LP.

The problem above extends to editing the LP with delete.constraint() / add.constraint(), which makes 'efficient' solution significantly slower than the naive approach of solving each LP cold.

Shakeel Gavioli-Akilagun
  • 1
  • 1
  • To get a better idea try this: `library(microbenchmark); for(i in 1:10) print(microbenchmark(lps.model, times = 10))` – G. Grothendieck Jan 15 '21 at 20:35
  • Thanks for the suggestion, microbenchmark shows pretty much the same thing. The issue is that the second time round the LP is already solved, so it doesn't make sense for it to take even as long as solving the original problem. – Shakeel Gavioli-Akilagun Jan 15 '21 at 20:55
  • I got these means on successive iterations of the code in my last comment so it does not seem to increase over time for me: 1200 1170 830 960 880 1160 1070 1020 880 – G. Grothendieck Jan 15 '21 at 21:59

0 Answers0