# From a performance/speed perspective, does the programming language matter if the solver used is the same?

Perhaps a silly question, I know... But just wondering if the programming language has an impact here if the solver used is the same? For instance, the same model formulation being solved using Gurobi in Python vs C++... Is the solver all that matters? Here I'm considering only general purpose programming languages and excluding languages such as AMPL as afaik it has some presolver mechanisms to simplify a problem.

• One nit: Programming Languages aren't (for the most part) inherently fast or slow. Implementations are. I realize this may seem a pedantic point if one is used to single-implementation languages like AMPL, but implementation is a huge consideration for a market standard general-purpose programming language like C++. Depending on the application, you may find more difference between gcc, clang, and Visual C++ than between one of those and Python. Sep 5 at 2:08
• @T.E.D. are C++ compilers so different that any one would even come near to Python's slowness? I'd find that surprising. Sep 5 at 15:02
• Yea, implementations are. Java 1.0-1.4 were dog slow compared to C++, but they have caught up for that in last 25 years, and arguable surpassed them even according to some benchmark (for throughput, not for bootstrap, unless you consider graalvm too). Python will catch up too, one day :) Sep 6 at 12:27
• Although inlining - the mother of all compiler optimizations - greatly favors static strong typed languages (think C++ and Java) over dynamic strong typed languages (Python) and even more over dynamic weak typed languages (JavaScript). Sep 6 at 12:27

The programming language used to setup the problem can matter under two circumstances. One is setup time of the problem this not only differs by programming language but also by the Gurobi interface used See page 30+.

The other situations in which it might matter are user callbacks. If one programming language is slower at those time spent in these is not available for the solver.

I am aware of situations where the Gurobi solver was perceived as slow by the user when the super majority of the time was spent setting up Gurobi while the problem was solved almost instantly See page 5. Your programming language and in particular your modeling language can matter. However switching languages can never provide more savings than the sum of setup time and time spend in usercall backs. Gurobi allows you to track the second.

For OptaPlanner (implemented in Java), we have done benchmarks and see no performance difference between use cases implemented in Java or Kotlin. This is no surprise, because both are running on a JVM. For other JVM languages Scala, Groovy, JRuby, Closure, ..., we haven't run enough benchmarks yet, but as far as I can tell, they are in the same ballpark, maybe a bit slower.

That being said, the version of JVM and the garbage collector have a severe impact on performance. Basically, the latest JVM is always faster, and a high-throughput GC is always faster than a low-latency GC. No surprises there.

For OptaPy, use cases implemented in Python with OptaPy are currently at least 20x slower than those implemented in Java with OptaPlanner. It's unclear how much is to due to the JPype magic that allows us to run in a plain Python environment. We're working with them upstream to minimize this loss.

We also did some experiments in GraalPython, which are significantly faster than JPype, but don't allow us to run in a plain Python environment. The Graal guys have several benchmarks for which graalpython is significantly faster than plain python, but graalpython is not feature complete yet IIRC.

• As pointed out in the other answer, this might be false if the solver uses user-provided functions. For instance, IpOpt can find the minimum of a function f by having the user provide functions f, f_jacobian and f_hessian. Time spent evaluating these three functions repeatedly during the optimization can be quite high.