perf(plan): 21% faster planning, and cars in the random benchmark

[springfall2008]

Three parity-exact speedups, plus the benchmark change that exposed the largest of them. Every step below was verified byte-identical across all 20 random scenarios on metric, cost, cost_pv10, cost_pv90, soc_min, soc_final, battery_cycles, export_kwh and import_kwh_battery.

The benchmark was blind to EV users

hit_car_window returns on its first line when num_cars is 0, and every random scenario had no car — so the suite could not see the cost of the code it guards, nor the car load in the prediction.

The generator now gives roughly half the scenarios 1-2 cars with 4-20 charging slots. The car block is drawn from a separate RNG stream seeded off the scenario seed, so re-generating reproduces every pre-existing parameter and data profile bit-identically and older baselines stay comparable — verified. Scenarios written before this carry no cars entry and still run car-less.

Turning cars on immediately cost +21.7% (44.08s → 53.66s), with individual scenarios up to 2.5x slower.

1. hit_car_window — the big one

It computed dp2(window["kwh"]) for every slot before the intersection test that discards nearly all of them. On a car scenario that made it the most expensive function in planning: 5.04s cumulative of an 11s plan, driving 15.9M dp2 and 16.1M round calls, while the C++ kernel took 1.4s.

Testing the intersection first and only rounding a slot that actually overlaps is 6.45µs → 1.08µs per call at 48 slots. dp2 is pure, so moving it last cannot change the answer.

It is still asked the same question about the same few windows ~1.2M times per plan — 99.8% of them from optimise_charge_limit_price_threads — so that caller now keeps a (start, end) -> hit dict for the length of the pass and hands it in, the same shape as the hit_charge_cache already beside it. Caller-owned rather than held on self, so the lifetime belongs to whoever knows when car_charging_slots can change.

	suite
with cars, unoptimised	53.66s
intersection before dp2	43.50s (−18.9%)
+ the cache	42.23s (−2.9%)

2. Levels pass — a selection rebuilt for things it doesn't depend on

The price-threshold scan in optimise_charge_limit_price_threads sits four loops deep, but which charge windows the threshold selects depends only on loop_price, max_charge_slots and try_charge_freeze — not on either export loop it is nested inside. It was rebuilt identically once per (max_export_slots, try_export_freeze) pair: ~52M iterations on the heaviest scenario, the hottest loop in planning.

Memoised on (max_charge_slots, try_charge_freeze) rather than hoisted, so the iteration order — and with it every tie-break in the search below — is untouched. Safe to share the cached objects because neither is mutated after it is built: all_n is copied into pred_item and charge_mods is only ever read.

Also folds the freeze skip into the selection condition, dropping a bare pass that was executing 19M times. 49.45s → 43.69s (−11.3%), and the function's self-time halved.

3. Kernel marshalling

double_array was handed [float(limit) for limit in limits] on every simulation; array.array already coerces to double in C, so both the float() and the intermediate list were wasted. 51.01s → 49.45s (−3.0%).

Two things deliberately not changed, having measured them and found them slower — both noted in comments so the next person doesn't repeat the experiment:

• window fields keep their list comprehensions: map(operator.itemgetter("start"), windows) is 0.88µs → 1.05µs at these list lengths
• predict_soc keeps its indexed loop: dict(zip(range(...), soc_out)) is 13.95µs → 18.69µs, because iterating a ctypes array boxes each double through the sequence protocol

line_profiler had suggested these were ~29% and ~13% of the wrapper; its per-line overhead badly inflates lines executed 73k times, and a microbenchmark told a different story. The first version of this commit measured +0.5% — no better than noise — which is what caught it.

Also here

• _save_results writes a trailing newline. json.dump leaves the file without one, so the end-of-file hook rewrote the checked-in baseline every time it was regenerated — the cause of the stray pre-commit.ci fixup commit on the previous branch.
• The checked-in random_results.json baseline is rebased onto the car scenarios; the old one described a car-less workload and would have shown a large spurious diff on all 11 car scenarios.
• Test registry reordering and a single-variant optimise_windows_kernel (springfall2008), with predbat_debug_pre_saving1's golden regenerated to match — the debug cases are sensitive to which tests precede them, as test_single_debug.py documents.

Testing

Full ./run_all and ./run_all --quick both pass; pre-commit clean. kernel_parity and model_kernel pass at each step.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR improves Predbat’s planning performance while keeping prediction parity, and updates the random benchmark so it exercises EV/car-planning code paths (which were previously skipped in all-random scenarios).

Changes:

• Add EV “cars” data generation + baseline updates for the random benchmark suite (YAML scenarios + JSON results), plus a trailing newline on saved benchmark outputs to avoid EOF hook churn.
• Speed up planning by optimizing hit_car_window (intersection-first + optional caller cache) and memoising charge-window selection inside optimise_charge_limit_price_threads.
• Reduce kernel wrapper overhead by allowing double_array/int32_array to accept iterables and removing unnecessary list/float() materialisation in kernel marshalling.

Reviewed changes

Copilot reviewed 5 out of 8 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
coverage/cases/random_scenarios.yaml	Adds cars blocks to scenarios so benchmarks cover EV charging interactions.
coverage/cases/random_results.json	Updates benchmark baseline results/timestamps/runtimes for the new scenario mix.
coverage/cases/predbat_debug_pre_saving1.yaml.expected.json	Regenerates a sensitive golden output to match the new ordering/behaviour.
apps/predbat/unit_test.py	Reorders/retags certain tests in the registry (affects --quick skipping).
apps/predbat/tests/test_random_scenarios.py	Adds car scenario generation/application and ensures benchmark outputs end with newline.
apps/predbat/tests/test_optimise_all_windows.py	Changes kernel test behaviour to run either kernel or Python depending on availability.
apps/predbat/prediction_kernel.py	Makes array marshalling accept iterables and removes avoidable allocations/conversions.
apps/predbat/plan.py	Planning hot-loop optimisations: hit_car_window caching + selection memoisation + reduced repeated logging.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.