CPLEX PythonAPI性能开销？

Question

更新

这个问题已经在OR exchange上得到了彻底的讨论和更新，我在那里交叉发布了它。在

原始问题

当我从命令行运行CPLEX 12.5.0.0时：

cplex -f my_instance.lp

在19056.99滴答中找到了一个最佳整数解。在

但是通过Python API，在同一个实例上：

^{pr2}$

现在所需的时间为97407.10滴答（慢了5倍多）。在

在这两种情况下，模式是并行的，确定性的，最多2个线程。我想知道这种性能低下是否是由于某些Python线程开销造成的，我尝试：

problem = cplex.Cplex("my_instance.lp")
problem.parameters.threads.set(1)
problem.solve()

需要46513.04个周期（即使用一个核心比使用两个核心快两倍！）。在

作为CPLEX和LP的新手，我发现这些结果相当混乱。有没有办法提高Python API性能，或者我应该切换到一些更成熟的API（即java或C++）吗？在

附件

以下是2线程决议的全部细节，首先是（共同）序言：

Tried aggregator 3 times.
MIP Presolve eliminated 2648 rows and 612 columns.
MIP Presolve modified 62 coefficients.
Aggregator did 13 substitutions.
Reduced MIP has 4229 rows, 1078 columns, and 13150 nonzeros.
Reduced MIP has 1071 binaries, 0 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.06 sec. (18.79 ticks)
Probing fixed 24 vars, tightened 0 bounds.
Probing time = 0.08 sec. (18.12 ticks)
Tried aggregator 1 time.
MIP Presolve eliminated 87 rows and 26 columns.
MIP Presolve modified 153 coefficients.
Reduced MIP has 4142 rows, 1052 columns, and 12916 nonzeros.
Reduced MIP has 1045 binaries, 7 generals, 0 SOSs, and 0 indicators.
Presolve time = 0.05 sec. (11.67 ticks)
Probing time = 0.01 sec. (1.06 ticks)
Clique table members: 4199.
MIP emphasis: balance optimality and feasibility.
MIP search method: dynamic search.
Parallel mode: deterministic, using up to 2 threads.
Root relaxation solution time = 0.20 sec. (91.45 ticks)

来自命令行的结果：

GUB cover cuts applied:  1
Clique cuts applied:  3
Cover cuts applied:  2
Implied bound cuts applied:  38
Zero-half cuts applied:  7
Gomory fractional cuts applied:  2

Root node processing (before b&c):
  Real time             =    5.27 sec. (2345.14 ticks)
Parallel b&c, 2 threads:
  Real time             =   35.15 sec. (16626.69 ticks)
  Sync time (average)   =    0.00 sec.
  Wait time (average)   =    0.00 sec.
                          ------------
Total (root+branch&cut) =   40.41 sec. (18971.82 ticks)

Python API的结果：

Clique cuts applied:  33
Cover cuts applied:  1
Implied bound cuts applied:  4
Zero-half cuts applied:  10
Gomory fractional cuts applied:  4

Root node processing (before b&c):
  Real time             =    6.42 sec. (2345.36 ticks)
Parallel b&c, 2 threads:
  Real time             =  222.28 sec. (95061.73 ticks)
  Sync time (average)   =    0.01 sec.
  Wait time (average)   =    0.00 sec.
                          ------------
Total (root+branch&cut) =  228.70 sec. (97407.10 ticks)

Answer 1

与此相关，我注意到python API在调用变量.add线性的_约束.添加. 似乎从CPXLgetcolindex调用的strcmp占用了大部分配置文件，也许字符串id是通过数组的线性搜索来处理的？在C++中，问题的产生是瞬时的。在

Answer 2

在这两种情况下，您可以尝试禁用预处理和剪切。然后重新运行这个实验，测试pythonapi本身是否在限制性能。如果禁用剪切后性能匹配，则查看Python剪切参数调整和默认值。在

我认为C++是性能的首选，但它会给开发带来严重的时间。只是我的意见。在