Overhead delle prestazioni dell'API Python CPLEX?

Question

Aggiornamento

Questa domanda è stata completamente discussa e aggiornata su OR exchange, in cui l'avevo crosspostata.

domanda originale

Quando lancio CPLEX 12.5.0.0 dalla riga di comando:

cplex -f my_instance.lp 

una soluzione ottimale intero viene trovata in 19056.99 zecche.

Ma attraverso l'API Python, sullo stesso esempio:

import cplex 
problem = cplex.Cplex("my_instance.lp") 
problem.solve() 

il tempo necessario ammonta ora a 97407.10 zecche (più di 5 volte più lenta).

In entrambi i casi, la modalità è parallela, deterministica, fino a 2 thread. Chiedendo se questo scarso rendimento è dovuto ad un sovraccarico filo pitone, ho provato:

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

richiesto 46513,04 zecche (cioè, utilizzando un core era due volte più veloce rispetto all'utilizzo di due!).

Essendo nuovo a CPLEX e LP in generale, trovo questi risultati piuttosto confusi. C'è un modo per migliorare le prestazioni dell'API Python, o dovrei passare a qualche API più matura (ad esempio, Java o C++)?

allegato

Qui ci sono tutti i dettagli delle risoluzioni 2-fili, prima il (comune) preambolo:

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) 

risultati dalla riga di comando:

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) 

Risultati dall'API Python:

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

Si potrebbe provare a disabilitare il presolettore e taglia in entrambi i casi. Quindi rieseguire l'esperimento per verificare se la stessa API Python sta riducendo le prestazioni. Se le prestazioni corrispondono dopo aver disattivato i tagli, quindi esaminare i parametri di Python cut tuning &.

A mio parere, il C++ è preferito per le prestazioni, ma può aggiungere molto tempo allo sviluppo. Solo la mia opinione però.

Answer 2

In relazione a ciò, ho notato che l'API python richiede molto più tempo per creare un problema dopo le chiamate a variables.add e linear_constraints.add. Sembra che strcmp chiamato da CPXLgetcolindex stia occupando la maggior parte del profilo, forse gli ID stringa vengono gestiti utilizzando ricerche lineari attraverso un array? In C++ la creazione di problemi è istantanea.