[olivier-lacroix]

Taking assign_coords for a spin, I realised it was way too slow. this PR fixes it. Sorry for not catching this sooner...

Note

The following content was generated by AI.

What

Model.assign_coords (from #955) relabelled containers by mapping each label through Index.map(dict(zip(master, new))), and rebuilt the dict once per container.

Two changes, both inside the #955 code:

1. Positional relabel. master.get_indexer(index) locates each container's labels and new.take(positions) selects the new values. get_indexer also replaces the separate isin(master).all() check, so one lookup does both jobs.

   # before, per container
   index.map(dict(zip(master, new)))
   
   # after, per container
   new.take(master.get_indexer(index))

   On a tz-aware DatetimeIndex, the rolling-horizon case the API is built for, Index.map returns an object array of Timestamps and pandas infers datetime64 back. That inference accounts for 16 ms of the 20 ms per container on pandas 3.1.0 (objects_to_datetime64), and the dict rebuild adds 6 ms.

2. One Dataset construction. reassign_coords writes the new index into the coordinate's original position and builds the dataset once, instead of Dataset.assign_coords(...) followed by a second Dataset(...) to restore the coordinate order. This is a small second gain (about 3 ms), not part of the speedup above.

Benchmark

30 containers (15 variables + 15 CSR constraints), 4380 tz-aware labels, Model(sparse=True), pandas 3.1.0, a fresh model per call, interleaved, best of 5:

change	Model.assign_coords
none (master)	809 ms
one Dataset construction only	805 ms
positional relabel only	11.5 ms
both	8.8 ms

Reproduction

import time
import pandas as pd
import linopy
from linopy import Model

idx = pd.date_range("2024-01-01", periods=4380, freq="30min", tz="Australia/Melbourne", name="time")
new = pd.date_range("2024-04-01", periods=4380, freq="30min", tz="Australia/Melbourne", name="time")

m = Model(sparse=True)
vs = [m.add_variables(coords=[idx], name=f"x{i}") for i in range(15)]
for i, v in enumerate(vs):
    m.add_constraints(v >= 0, name=f"c{i}")

best = 1e9
for _ in range(3):
    t0 = time.perf_counter()
    m.assign_coords(time=new)
    best = min(best, time.perf_counter() - t0)
print(f"{best * 1000:.1f} ms")

Checklist

• AI-generated content is marked (see AGENTS.md).
• Code changes are sufficiently documented; i.e. new functions contain docstrings and further explanations may be given in doc.
• Unit tests for new features were added (if applicable).
• A note for the release notes doc/release_notes.rst of the upcoming release is included.
• I consent to the release of this PR's code under the MIT license.

[codspeed]

Merging this PR will not alter performance

✅ 181 untouched benchmarks
⏩ 181 skipped benchmarks¹

---

_{Comparing olivier-lacroix:perf/assign-coords-relabel (314a6ed) with master (b9ec07b)²}

Footnotes

1. 181 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on master (2ace7b3) during the generation of this report, so b9ec07b was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[olivier-lacroix]

Rebased onto master at 8736b35 (2026-10-29). Re-measured against a worktree of 8736b35, interleaved runs, best of 3 assign_coords calls:

checkout	assign_coords
8736b35	914 ms (871 to 967)
this branch	9.4 ms (8.5 to 14.1)

The gain is about 100x, versus 280x in the original benchmark.

[FabianHofmann]

I fail to understand the changes when scanning over them. is the problem perhaps within maybe_infer_to_datetimelike being slow? could you remove the inline comments from the code please?

[olivier-lacroix]

@FabianHofmann , yes, the slowness is pandas' datetimelike inference. Index.map(dict) on a tz-aware DatetimeIndex produces an object array of Timestamps and pandas converts it back to datetime64. The dict rebuild was adding to the costs.

Inline comments removed & code simplified. The 'equals' branch is gone as benefits are super tiny, not worth an extra branch.

Best of 5: 809 ms on master, 11.5 ms with the relabel alone, 8.8 ms with both changes. The PR description now has the before/after and this table.