Testing new rust-based core for PuLP

[pchtsp]

I'm working on a new version of PuLP with a Rust core that's supposed to bring good efficiency gains.
The code is being kept in a separate branch for now: https://github.com/coin-or/pulp/tree/rust_core

I recently built wheels and uploaded them into a pre-release on pypi so it's easy to install and test by end users.

In case someone wants to try it out with a large problem (or with any problem):

python -m pip install pulp==4.0.0a2

or with uv:

uv add pulp==4.0.0a2

You need to explicitly pin the version or you won't get the pre-release.

Let me know if something breaks THAT'S NOT SUPPOSED TO BREAK (see: https://github.com/coin-or/pulp/tree/rust_core?tab=readme-ov-file#quickstart) for the syntax change in variable creation (e.g., prob.add_variable() instead of LpVariable()).

[christiansegercrantz]

Exciting! Would you elaborate on the goals of this? Is it

1. Speed
2. (Memory) safety
3. Both
4. Other

I tried running some benchmarks and the 4.0.0a2 came out close to or even slower than the current latest version. I do not doubt I may have had bad benchmarks, do you have any to show?

[pchtsp]

For the goals, the long answer is here: https://pchtsp.github.io/blogue2.0/2026/03/17/pulp-rust-core/
The short answer is: "out of genuine curiosity and joy of learning".

I recommend you try version 4.0.0a9, which has been improved quite a bit, with the help of profiling.
As per benchmarking: I've used some syntetic models.
Also, the guys at polar-high were running a basic benchmark across modellers recently and I added pulp: https://github.com/nodal-tools/polar-high/tree/main/benchmark

It's roughly 60% faster than v3.3 on the one benchmark I ran. Comparing to other modellers, it's similiar speed as pyomo to build and it seems it's the modeller with the least amount of peak memory needed to build a model.

This is the quick test that I ran (requires having uv installed):

uv run --no-project --with "pulp[cbc]==4.0.0a9" python -m timeit "import pulp; from pulp.tests.bin_packing_problem import create_bin_packing_problem; create_bin_packing_problem(100, 99)"
uv run --no-project --with "pulp==3.3.0" python -m timeit "import pulp; from pulp.tests.bin_packing_problem import create_bin_packing_problem; create_bin_packing_problem(100, 99)"

Finally, it's important to notice that there are two functions that help get the most out of the rust core and that replace "lpSum":

• "lpSum_vars" is a function that takes a list of variables and sums them.
• "lpSum_vars_coefs" is a function that takes a list of tuples (variable, coefficient) and returns the sum of the product.

[christiansegercrantz]

This a bit on the side (while I run my benchmarks):

Interesting take that

I've always argued that the performance of the modelling library is usually irrelevant when considering the time it takes to solve an LP/MIP problem by any solver

I have faced this exact scenario, building the model could take up to 5 minutes while solving was usually a 5-30second business. It's a reason I am now looking for another framework, as pulp was far too slow in this regard.

Disclaimer: it might be that the problem could be written much more efficiently as well, but then why would I use pulp for its readability and not instead opt for SciPy for pure speed.

Edit: To add more context, we need to create business optimisations on-demand from a UI, so they need to be fast, this means of course that the total time needs to be short. I understand of course that it matters little if the problem modelling takes 1s or 10 minutes if the actual solving requires the magnitude of hours.

[christiansegercrantz]

Here is a screenshot from my benchmarking. Disclaimer: specific problem setup and the benchmarks are AI built so the possibility for errors do exist.

That being said, I am surprised at how small the gain is given how large the overhead of python object creation is in the stable version. E.g. at 1m vars the difference is 15.7s vs 9.0s. Quite significant in terms of relative difference, but since the both scale in the same way (note log axis) they aren't able to handle bigger problems nearly at all.

I'm seeing if I can make the full benchmarks public if there's an interest for that.

[pchtsp]

I'm not sure if I can promise to check the benchmarks. The only thing I can say is that pulp modelling efficiency is highly sensitive to the python code that's written to build it. If the python data processing/wrangling is slow/ inefficient: there's nothing to do. I suggest you profile the code to understand if most of the time is spent in pulp functions or python code.

[christiansegercrantz]

I'm not sure if I can promise to check the benchmarks.

No worries, it was more whether you are interested and wanted to see if these are misleading.

If the python data processing/wrangling is slow/ inefficient: there's nothing to do. I suggest you profile the code to understand if most of the time is spent in pulp functions or python code.

This is getting way off topic now, but when I profiled the production code I had, the largest overhead came from object creation in PuLP, LpExpression if I don't remember wrong.

[greg19]

Hey, some feedback on the rewrite from my side :)

Generally, I like the fact that PuLP is so Python-centered and easy to use. I prefer to write my code as a standard Python lists, and using familiar Python features like list and dictionary comprehensions.

When it comes to AI, I'm not bought on the "coding is solved" narration pushed by the providers of AI models/tools. I believe that human expertise is very valuable and needed for a good end result. The PuLP project is so small that AI probably can do a perfect job in re-writing it from one language to another when it has full specification, but I'm not that confident it will be beneficial in the long term.

My biggest concern that there is no one experienced in Rust to do the code reviews of the AI work. Over the recent months, I have seen situations where a project was flooded with so many PRs where the author had no idea what the AI wrote for them the maintainers had to include a "this is not AI slop and I take the responsibility for it" checkbox in the PR template. I've seen so bad AI code in the languages I know, that I don't want to fall into the Gell-Mann amnesia with the languages I don't know.

I do believe we should write good software, and that includes performance. I think Python is a really good scripting "frontend" language for libraries, but not that good for their implementation. I like the architecture of a python interface backed by a more performant language. However, I think you accurately noticed that being fully written in Python made it easier to read, understand and contribute to the project. We should take into the account the profile of a potential contributor, and in my opinion they are much less likely to know Rust than Python, which considerably shrinks the potential for contributions.

Also, while AI is really great for learning a new skill, I'm not sure if a popular open-source repository with millions of downloads is a good place for such adventures.

I think that a migration to a more performant language can be a good thing, but it should be overseen by someone experienced in the language, and AI output should be taken with a big caution.

[greg19]

One regression that I found is that you can no longer modify the constraints after adding them to the program. For example, this code used to work:

>>> import pulp as lp
>>> prob = lp.LpProblem()
>>> x = lp.LpVariable('x')
>>> constr = x <= 2
>>> prob += constr
>>> constr[x] = 2
>>> constr
2*x + -2 <= 0
>>> prob.constraints
OrderedDict({'_C1': 2*x + -2 <= 0}

In the new version, the constraint doesn't get updated:

>>> import pulp as lp
>>> prob = lp.LpProblem()
>>> x = prob.add_variable('x')
>>> constr = x <= 2
>>> prob += constr
>>> constr[x] = 2
>>> constr
2.0*x + -2.0 <= 0
>>> prob.constraints()
[1.0*x + -2.0 <= 0]

To back up why this could be useful, consider an example where I want to create a plot where the x-axis is one of the coefficient in the constraints, and the y-axis is the objective value:

import pulp as lp
import matplotlib.pyplot as plt
import numpy as np

prob = lp.LpProblem()
var = prob.add_variable('var')
constr = ...
# fill prob with some constraints and objective

xs = np.linspace(0, 3, 20)
ys = []
for x in xs:
    constr[var] = x
    prob.solve()
    ys.append(prob.objective.value())

plt.plot(xs, ys)

I see in the source code that the immutability is intentional. @pchtsp can you share the rationale behind this change? It seems very unintuitive for me.

[christiansegercrantz]

This actually looks like an anti-pattern. Changing constraints ones passed to the model doesn't sounds like a good idea, I think immutable constrains would make a lot more sense. To re-create the "why this is useful" can't you just remove the old constraint and add a new?

[greg19]

My expectation is that the LpProblem.objectives is a standard container. Like when I add an object to an array or dictionary (as a value), it does not make a deep copy but keeps a reference. If I hold this reference outside the container, and I modify the contents, it will still be modified inside the container.

Like the famous Python snippet:

>>> arr = [[0]*3]*3
>>> arr[0][0] = 1
>>> arr
[[1, 0, 0], [1, 0, 0], [1, 0, 0]]

If I would see this behavior proposed by someone, I'd probably also be against it and say it's an anti-pattern. But when you think longer about it, it actually makes sense.

I see how you can think this is an anti-pattern, but I also think we should fit into the greater Python environment. Ideally, a person who programmed in Python shouldn't need to consult the documentation other than "getting started". Everything should work as they expect, as it works in the general Python ecosystem.

By the way, there is currently no way to remove a constraint as far as I know.

[christiansegercrantz]

Like when I add an object to an array or dictionary (as a value), it does not make a deep copy but keeps a reference. If I hold this reference outside the container, and I modify the contents, it will still be modified inside the container.

This is no the part I was referring to as an anti-pattern. As I said

immutable constrains would make a lot more sense

It's more like this comparison

>>> arr = ((0,)*3,)*3
>>> arr[0][0] = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    arr[0][0] = 1
    ~~~~~~^^^
TypeError: 'tuple' object does not support item assignment

If a change is to be made, I'd rather see the change be that constraints can be deleted or reassigned to new constraint but not that constraints can be modified. Similarly to other immutable, using operations that would modify the existing object could just return a new object instead.

[greg19]

Are you saying that the whole LpAffineExpression should be immutable?

[pchtsp]

Hello @greg19 thanks for pointing this out. Interesting! I think you found an unintentional backwards incompatibility. I don't think that was an explicit functionality (and I've never used that and I don't think it was ever documented). I've always re-created a model from scratch.
I believe the impossibility to do it now comes from the migration away to using constraints as dictionaries. Having said that, I don't think there's any reason why we should not support that still.

Can you create (1) an issue and then (2) a PR with a proposed fix? Thanks again.

[greg19]

Hi, I've created #933.

I'm not experienced with Rust, so I am not the person that will give you a well thought out architecture in this language. From my experience with extending Python in C, I'd just store a strong reference to the PyObject of the constraint.

As a side note, that's also what I would do when storing variables in the program. I would just make it as before, where declaring a new variable is calling LpVariable constructor, and when adding objective/constraints to the program I'd store the strong references to the variables in the model.

I don't know if PyO3 doesn't support holding strong references, or you AI just decided it doesn't care and didn't tell you it does. But this is a rather fundamental feature of Python, so I'd be surprised if it couldn't be done. To be honest, the more I look at this rewrite, the less I like it, and I'm less if I want to put my time into rescuing this AI generated architecture. But I can keep pointing you stuff to fix if you want.

[pchtsp]

I'm sorry maybe you misunderstood me:

1. I'm not asking your architectural opinion, I'm asking if you want to contribute to this project or not. If you don't, just say no.
2. The architectural decision are my own not "my AI". You have every right to disagree.
3. I'm not asking you to rescue anything: there's nothing to rescue.
4. You're not really doing me a favor by pointing out stuff that doesn't work for you. I don't get paid from fixing bugs for you. You're doing a favor to other users and to yourself. But what would really help them (and you) is for you to provide solutions. Again, if you don't want to or cannot: it's fine.

This is an open source project maintained mainly by me + the few people that take the time to contribute for free. It's your choice if you want to be part of it.

[greg19]

Thanks, maybe I expressed my lack of interest in contributing to this part of the codebase too harshly. I didn't want to sound demanding or entitled, I know open source is hard. Sorry. I wanted to say that I'm not that familiar in Rust to take the responsibility of not breaking something I didn't think of.