Skip to content

Python api performance improvement #1615

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Iroy30 wants to merge 22 commits into
base: main
Choose a base branch
from
Open

Python api performance improvement #1615

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
22 commits
Select commit Hold shift + click to select a range
429d93e
Improve repeated-solve Python API performance
Iroy30 Jul 20, 2026
6834882
Optimize repeated Python model updates
Jul 23, 2026
2b42019
Delete script_perf_eval.py
Iroy30 Jul 24, 2026
a2ac39a
Merge branch 'main' into python_api_performance
Iroy30 Jul 24, 2026
b8049b8
fix pre-existing bug
Jul 29, 2026
0c6da6c
Skip stale tracking on solution attribute writes
Jul 29, 2026
acaf5b0
Merge remote-tracking branch 'iroy30/python_api_performance' into pyt…
Iroy30 Jul 30, 2026
8a01887
Merge branch 'main' into python_api_performance
Iroy30 Jul 30, 2026
744065d
Fix Q lifetime and MIPStart clear on warm updates.
Aug 4, 2026
98cda41
Merge branch 'main' into python_api_performance
Iroy30 Aug 4, 2026
5826f3b
formatting
Iroy30 Aug 4, 2026
6d4d4ed
fix conflict
Iroy30 Aug 4, 2026
0974eb9
address reviews
Iroy30 Aug 10, 2026
52b4f0b
Merge branch 'main' into python_api_performance
Iroy30 Aug 13, 2026
7f45787
move slack computation to cython
Iroy30 Aug 13, 2026
66b2f0b
fix read to add quadratic constraints and cache
Iroy30 Aug 26, 2026
634c910
Merge branch 'main' into python_api_performance
Iroy30 Aug 26, 2026
7e522fa
Update solution.py
Iroy30 Aug 26, 2026
089566b
Merge branch 'main' into python_api_performance
Iroy30 Aug 28, 2026
c3a64fd
Merge branch 'main' into python_api_performance
Iroy30 Aug 28, 2026
dd8d449
Merge branch 'main' into python_api_performance
Iroy30 Aug 28, 2026
670e5bf
fix formatting and row senses
Iroy30 Aug 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion python/cuopt/cuopt/linear_programming/data_model/data_model_wrapper.pyx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# SPDX-FileCopyrightText: Copyright (c) 2023-2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved. # noqa
# SPDX-FileCopyrightText: Copyright (c) 2023-2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved.
# SPDX-License-Identifier: Apache-2.0


Expand Down Expand Up @@ -292,6 +292,9 @@ cdef class DataModel:
return self.problem_name

def set_data_model_view(self):
# Rebind from scratch so optional fields that were previously set but
# are now empty (e.g. Q after QP -> LP) do not stick in the C++ view.
self.c_data_model_view.reset(new data_model_view_t[int, double]())

@coderabbitai coderabbitai Bot Aug 10, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail
rg -n -C 6 'data_model_view_t|except \+' \
  python/cuopt --glob '*.pxd' --glob '*.pyx'

Repository: NVIDIA/cuopt

Length of output: 50368

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

printf '%s\n' '--- data_model.pxd ---'
cat -n python/cuopt/cuopt/linear_programming/data_model/data_model.pxd | sed -n '25,55p'

printf '%s\n' '--- C++ declarations/definitions ---'
rg -n -C 5 'class data_model_view|data_model_view\(|~data_model_view' \
  cpp python --glob '*.{hpp,h,cpp,cc,pyx,pxd}'

printf '%s\n' '--- related constructor declarations ---'
rg -n -C 3 'cdef cppclass data_model_view_t|data_model_view_t\(\)' \
  python/cuopt --glob '*.pxd' --glob '*.pyx'

Repository: NVIDIA/cuopt

Length of output: 18011

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

printf '%s\n' '--- data_model_view_t class definition ---'
cat -n cpp/include/cuopt/mathematical_optimization/io/data_model_view.hpp | sed -n '45,95p'

printf '%s\n' '--- Cython availability ---'
if command -v cython >/dev/null 2>&1; then
  cython --version
else
  printf '%s\n' 'cython: unavailable'
fi

Repository: NVIDIA/cuopt

Length of output: 2916

🌐 Web query:

Cython cppclass omitted default constructor new Foo() exception handling except + implicit constructor declaration

💡 Result:

In Cython, when using a C++ class that has no explicitly declared constructor, Cython does not automatically assume a default constructor exists for the purposes of code generation, often leading to compilation errors or crashes if you attempt to instantiate the class [1][2]. If a class has only one constructor and it is a nullary (default) constructor, Cython may allow it without explicit declaration, but it is best practice to declare it [3][4]. Regarding exception handling: 1. Constructor Exception Handling: If your C++ constructor can throw an exception, you must explicitly declare it with except + [3][4]. If you omit this, C++ exceptions thrown during construction will not be caught or translated into Python exceptions, which can lead to undefined behavior or process termination [3][4][5]. 2. Heap Allocation (new Foo()): When you use new Foo() in Cython, the generated C++ code performs a raw call to the new operator. If you have not declared the constructor with except +, any exception raised during the execution of that constructor (or the allocation itself) will not be handled by Cython [5]. Even if the constructor logic is simple, declaring the constructor as Foo() except + is recommended to ensure that memory allocation failures or constructor-internal exceptions are safely translated into Python exceptions (e.g., MemoryError or others based on the C++ exception type) [3][4][5]. 3. Implicit Constructor Declarations: Because Cython requires explicit declarations for exception propagation, relying on "implicit" declarations is discouraged [5]. If a class lacks a nullary constructor, Cython will fail to stack-allocate it [6][7]. Developers working with such classes often use workarounds such as: - Defining a static factory function that returns the object and declaring it with except + [8]. - Using std::shared_ptr or std::unique_ptr to manage the object on the heap, avoiding the need for a stack-allocated default constructor [9]. In summary, you should explicitly declare your constructors and use except + whenever the C++ code has the potential to raise an exception, including during memory allocation or object initialization, to ensure robust Python-C++ exception bridging [3][4][5].

Citations:

Declare data_model_view_t() with except + in data_model.pxd.

The new data_model_view_t[int, double]() call can otherwise let C++ allocation or construction failures escape the Python boundary.

🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@python/cuopt/cuopt/linear_programming/data_model/data_model_wrapper.pyx` at
line 297, Update the Cython declaration for data_model_view_t in data_model.pxd
to use except +, ensuring failures from the constructor invoked by
self.c_data_model_view.reset are propagated through the Python boundary.

Source: Path instructions

cdef data_model_view_t[int, double]* c_data_model_view = (
self.c_data_model_view.get()
)
Expand Down
Loading
Loading