Remove expression `_args_` tuple by jsiirola · Pull Request #4022 · Pyomo/pyomo

jsiirola · 2026-08-17T19:00:21Z

Fixes # .

Summary/Motivation:

@bknueven reached out a couple months ago pointing out that the recent work to standardize the internals of the expression system (and in particular, that LinearExpression should more directly inherit from SumExpression) had the indirect effect of tripling the memory used by a LinearExpression object:

I traced the issue we are having with constraints and memory, and I think it goes back to changes made to LinearExpression a few years back. When I calculate the memory needed to store a single (coefficient, variable) entry in a LinearExpression object, I come up with 120 bytes per-entry for our use case:
MonomialTermExpression : 40 bytes
    MonomialTermExpression._args_ : 40 bytes
          pointer-to-Pyomo-var: 8 bytes
          pointer-to-Python-double: 8 bytes
                    Python-double: 24 bytes
Blow this up to 40000 entries per row and a few hundred rows, and we’re in GBs of memory.

In the old implementation, LinearExpression would store two lists, which for the marginal entry in this use case would cost only 40 bytes instead of 120 bytes.

@bknueven's request was to revert the LinerExpression storage model back to using a pair of lists. The challenge there is that the "pair of lists" model doesn't gracefully handle incrementally building LinearExpression objects through the normal operator overloading process (in large part because of challenges with handling constants that appear within the summation) -- and the fact that Pyomo's expression system now "automatically" recognizes and creates LinearExpression objects is a big part of the benefit from that previous rewrite.

As a result, this PR does not re-implement the "pair of lists" data structure (nor does it resolve all the memory degradation). Instead, it proposes a compromise that removes the _args_ tuple from MonomialTermExpression (and all other Expression objects). Storage now depends on the Expression object:

unary operators store the single argument in the _arg attribute
binary operators store the arguments in the _l_arg and _r_arg attributes
some specialized ternary operators (e.g., Expr_IF) store the operands in named attributes
n-ary operators continue to store the arguments in either a tuple or list as the _args attribute.

This reduces the marginal memory overhead from 120 bytes/entry to 80 bytes per entry.

It also significantly improves model creation time (and marginally improves the lp and nl writers). In my opinion, the slight performance degradation in the GAMS writer is OK, as that writer needs to be completely redesigned (to bring it in line with the current LP/NL writers).

Changes proposed in this PR:

remove standard _args_ attribute from all expression classes
implement custom (tuple-free) storage solutions for 1, 2, and some 3-operand expression nodes.
standardize the CP expression system to leverage / reuse more of the infrastructure developed for the numeric expression system
remove most (but not all) instances of accessing private argument attributes outside of the class that defines them (and the core expression generation callbacks)
clean up some inconsistencies between numeric and boolean expression systems (e.g., value should be a property)

AI-Use Disclosure

AI tools were NOT used during the preparation of this PR

or

Notes for reviewers (optional):

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

I agree my contributions are submitted under the BSD license.
I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

… into expr-remove-args-tuple

jsiirola · 2026-08-17T19:05:24Z

I do think there there is still a need / use for a more memory-efficient expression object for @bknueven's use case, but I think that should be done separately (probably through a re-thought MatrixConstraint expression object).

codecov · 2026-08-17T20:03:58Z

Codecov Report

❌ Patch coverage is 95.59585% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.93%. Comparing base (ce205a5) to head (85e9f88).

Files with missing lines	Patch %	Lines
pyomo/core/expr/numeric_expr.py	94.79%	5 Missing ⚠️
pyomo/core/expr/boolean_value.py	70.00%	3 Missing ⚠️
pyomo/core/expr/logical_expr.py	95.12%	2 Missing ⚠️
pyomo/core/expr/template_expr.py	89.47%	2 Missing ⚠️
pyomo/contrib/appsi/solvers/maingo_solvermodel.py	50.00%	1 Missing ⚠️
...ib/cp/scheduling_expr/step_function_expressions.py	97.05%	1 Missing ⚠️
pyomo/core/base/expression.py	92.30%	1 Missing ⚠️
pyomo/core/expr/expr_common.py	83.33%	1 Missing ⚠️
pyomo/core/expr/relational_expr.py	95.65%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4022      +/-   ##
==========================================
- Coverage   89.93%   89.93%   -0.01%     
==========================================
  Files         917      917              
  Lines      109135   109107      -28     
==========================================
- Hits        98148    98121      -27     
+ Misses      10987    10986       -1

Flag	Coverage Δ
builders	`29.11% <50.25%> (+0.02%)`	⬆️
default	`86.12% <95.59%> (?)`
expensive	`35.09% <60.62%> (?)`
linux	`87.66% <95.59%> (-1.98%)`	⬇️
linux_other	`87.66% <95.59%> (-0.01%)`	⬇️
oldsolvers	`27.57% <56.47%> (+0.02%)`	⬆️
osx	`83.09% <95.33%> (-0.01%)`	⬇️
win	`85.41% <95.33%> (-0.01%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

mrmundt · 2026-08-21T13:59:15Z


-    def nargs(self):
-        return 2
+    __slots__ = ('_l_arg', '_r_arg')


For left and right?

mrmundt · 2026-08-21T14:00:36Z

+        IntervalVar, and the SequenceVar
    """

+    __slots__ = ('_before', '_after', '_sequence')


You use before/after here but predecessor/successor in L#95. It would be better to pick one probably, considering that you are referring to them in the same way?

mrmundt · 2026-08-21T14:10:58Z

+        # starts with -1.  We can safely replace that entry with the
+        # list of processed operands.
+        #
+        # Note also, the parent of the root node (i.e., parent[0] is -1,


Suggested change

# Note also, the parent of the root node (i.e., parent[0] is -1,

# Note also, the parent of the root node (i.e., parent[0]) is -1,

mrmundt · 2026-08-21T14:14:13Z

+        i: int
+            Index of the child argument to return
+
+        Returns: The i-th child node.


Feels a bit redundant to the main description 😛

mrmundt · 2026-08-21T14:16:13Z

+relocated_module_attribute(
+    'UnaryBooleanExpression',
+    'pyomo.core.expr.logical_expr.UnaryBooleanExpression',
+    version='6.10.1.dev0',


Isn't it 6.10.2.dev0?

mrmundt · 2026-08-21T14:17:51Z


+@deprecated(
+    "UnaryBooleanExpression is no longer used; see UnaryExpression_Mixin",
+    version="6.10.1.dev0",


Same comment as earlier - I think it should be 6.10.2.dev0

jsiirola added 21 commits May 18, 2026 15:31

Remove standard expression _args_ attribute

74b1098

Update logical ._args from list to tuple

fab9989

Misc doc updates

7fed39b

Deprecate UnaryBooleanExpression and BinaryBooleanExpression

0e58a97

Standardize on _args over _args_

3b11a57

Move BooleanConstant.value to be a property

e1da1dc

Merge branch 'main' into expr-remove-args-tuple

8416e7f

Merge branch 'main' into expr-remove-args-tuple

5aa86be

Resolve import errors

f7eeffd

Rework grb_nl_to_pyo_expr to not require private attribute access

9677f3b

Update tests to reflect more accurate grb_nl_to_pyo_expr handling

0ccd6e2

Propagate use of Unary, Binary, and Nary mixins into CP expressions

336c442

Deprecate NaryBooleanExpression

3867b15

Resolve typos

348aac8

Update FBBT tests to create proper expression nodes

9f3953d

Update PrecedenceExpression internal storage to verify number of args

d36f738

Abstract the variable-lenth argument logic out of SumExpression

fd8c93c

Rework step functions to leverage standard expression mixins

d06e471

Reduce external access to private attributes

d37caf6

Remove unused code

d4bf24b

Merge remote-tracking branch 'refs/remotes/me/expr-remove-args-tuple'…

85e9f88

… into expr-remove-args-tuple

blnicho requested review from blnicho, emma58 and mrmundt August 18, 2026 18:57

mrmundt requested changes Aug 21, 2026

View reviewed changes

Navigation Menu

Uh oh!

Remove expression `_args_` tuple - #4022

Remove expression `_args_` tuple#4022
jsiirola wants to merge 21 commits into
Pyomo:mainfrom
jsiirola:expr-remove-args-tuple

jsiirola commented Aug 17, 2026 •

edited

Loading

Uh oh!

jsiirola commented Aug 17, 2026

Uh oh!

codecov Bot commented Aug 17, 2026 •

edited

Loading

Uh oh!

mrmundt Aug 21, 2026

Uh oh!

mrmundt Aug 21, 2026

Uh oh!

mrmundt Aug 21, 2026

Uh oh!

mrmundt Aug 21, 2026

Uh oh!

mrmundt Aug 21, 2026

Uh oh!

mrmundt Aug 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	# Note also, the parent of the root node (i.e., parent[0] is -1,
	# Note also, the parent of the root node (i.e., parent[0]) is -1,

Uh oh!

Conversation

jsiirola commented Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Fixes # .

Summary/Motivation:

Changes proposed in this PR:

AI-Use Disclosure

Legal Acknowledgement

Uh oh!

jsiirola commented Aug 17, 2026

Uh oh!

codecov Bot commented Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

mrmundt Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

mrmundt Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

mrmundt Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

mrmundt Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

mrmundt Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

mrmundt Aug 21, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jsiirola commented Aug 17, 2026 •

edited

Loading

codecov Bot commented Aug 17, 2026 •

edited

Loading