Performance of MVar vs. list of Var
Answered
Getting more familiar with gurobi I recently updated my variable initialization in a complex model from lists of vars
vars = []
for _ in range(timesteps):
vars.append(model.addVar())
to using MVars (like you're probably supposed to)
vars = model.addMVar(timesteps)
I noticed however, that the simulation runs a lot slower when using MVar instead of list(Var). I created an mre (code at the bottom) which shows both variants of the model solving in the same amount of time and giving the same results, however the time needed to continue the code after model.optimize() (measuring time.time before and after the gurobi model segments) is vastly different and depends on the amount of variables in the list/in the MVar. When selecting a low number (up to about 1000 timesteps) the list of Var continues faster, for higher numbers the MVars continue faster. In case of my complex model the duration from entering the optimization to continuing afterwards is about 2 seconds, with MVars about 25. The optimization ouput shows same durations for everything.
Does anybody know why this could happen and what i could do about it?
I really want to use MVars :D
Best regards
import gurobipy as gp
from gurobipy import GRB
import numpy as np
import time
timesteps = 1000
# Model with MVars
start = time.time()
m1 = gp.Model('model_mvar')
x1 = m1.addMVar(timesteps, lb=0, ub=1, vtype=GRB.CONTINUOUS, name='load')
m1.setObjective(x1.sum(), GRB.MAXIMIZE)
m1.setParam('OutputFlag', 1)
m1.optimize()
end = time.time()
print("\nTime 1", end - start, "\n")
# Model with list of variables
start = time.time()
m2 = gp.Model('model_var')
x2 = []
for i in range(timesteps):
x2.append(m2.addVar(lb=0, ub=1, vtype=GRB.CONTINUOUS, name='load'))
m2.setObjective(np.sum([x2[i] for i in range(timesteps)]), GRB.MAXIMIZE)
m2.setParam('OutputFlag', 1)
m2.optimize()
end = time.time()
print("\nTime 2", end - start, "\n")
-
Hi Lukas,
Getting fast build times with MVars requires using methods which work efficiently with MVars. Sometimes figuring out what this is requires a bit of experimentation.
If I replace
m1.setObjective(x1.sum(), GRB.MAXIMIZE)
with
m.setObjective(x1@np.ones(timesteps), GRB.MAXIMIZE)
then I get the MVar code running about 4 times faster.
You can accurately benchmark with the following code snippet (which accounts for background noise on your machine that affects execution time):
import numpy as np
import timeit
setup = """
import gurobipy as gp
from gurobipy import GRB
import numpy as np
timesteps = 1000
m = gp.Model()
"""
statement1= """
x = m.addMVar(timesteps, lb=0, ub=1, vtype=GRB.CONTINUOUS, name='load')
m.setObjective(x@np.ones(timesteps), GRB.MAXIMIZE)
"""
statement2= """
x = {
i:m.addVar(lb=0, ub=1, vtype=GRB.CONTINUOUS, name=f'load_{i}')
for i in range(timesteps)
}
m.setObjective(np.sum([x[i] for i in range(timesteps)]), GRB.MAXIMIZE)
"""
factor = np.divide(
np.min(timeit.repeat(stmt=statement1, setup=setup, number=1, repeat=1000)),
np.min(timeit.repeat(stmt=statement2, setup=setup, number=1, repeat=1000)),
)
print(f"MVars takes {factor:.2%} of the time.")- Riley
0 -
Hey Riley, thanks for the answer.
I tried using your code as well as @np.ones instead of np.sum in my own code.
I noticed that while @np.ones is in fact faster, at a low number of timesteps and/or repeats lists of Vars still perform better. It's mainly the 1000 repeats that make MVars faster.I'm not familiar with how the repeat function is handled, could the time difference occur at initialization, meaning MVar initializes slower, which gets less significant the more often you repeat the segment?
0 -
Hey Lukas,
at a low number of timesteps... lists of Vars still perform better
It does appear to be the case. I guess there is a fixed cost in performing the matrix multiplication which is a more significant portion of the time when timestamps is small
at a low number of ... repeats lists of Vars still perform better
I don't think this is true. The repeats=1000 argument in the timeit.repeat function just tells the timeit module to perform the statement 1000 times, and it will return a list of 1000 individual times. The result becomes more statistically robust as the number of repeats increases, but the actual times should be similar.
- Riley
0 -
I probably should have tested more cases, but setting repeat to 1 results in "MVars takes 908.07% of the time.", for anything above 1 MVars is significantly faster. At 2 it's 14.58%, starting at 10 it's about 10%. Like you said there probably is some sort of fixed duration when executing the statement for the first time, for my complex model I'll work with lists of vars first and see if I can restructure things afterwards.
Best regards,
Lukas0
Please sign in to leave a comment.
Comments
4 comments