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.
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.
Your mileage may vary.
As far as I know, the core of many of the mathematical optimization solvers have been designed with C/C++ and other programming languages are treating as an exchange layer. It does not affect directly the solving time, but for the pre-processing or post-processing, it is important. For example, I am aware that initializing/manipulating data with python might be somewhat slower than others like java.