feat(genetic): make the fitness cache size configurable (#1376)

The per-run fitness cache of the GENETIC optimizer is unbounded. It
grows with individuals x generations (~110k keys at 300 x 400, about
1.1 kB each, 1.6 kB with an EV) and adds 120-170 MB to the peak memory
of a run, while only 6-15 % of the lookups hit. On 512 MB boards this
is the largest part of the optimizer's memory.

Add optimization.genetic.fitness_cache_max_entries:

- None (default): unbounded, the previous behaviour.
- 0: no cache; every genome is evaluated.
- N > 0: at most N keys. The cache is then an OrderedDict and evicts
  the oldest key first (FIFO, O(1)); LRU would cost bookkeeping on
  every hit for a cache that rarely hits.

A cache hit returns exactly what the deterministic evaluation would
return, so the plan for a fixed seed is identical with any setting.

Co-authored-by: Christin <christin@BigBrother.bikini.bottom.zone>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Andreas <drbacke@gmx.de>
This commit is contained in:
Christin
2026-10-11 09:19:33 +02:00
committed by GitHub
co-authored by Christin Claude Opus 5.5 Andreas
parent ecec39fcd8
commit 14d8587c9c
8 changed files with 294 additions and 9 deletions
+1
View File
@@ -258,6 +258,7 @@
"individuals": 400,
"generations": 400,
"seed": null,
"fitness_cache_max_entries": null,
"measurement_max_age_seconds": 300,
"tail_horizon_hours": 48,
"terminal_value_mode": "AUTO",
+5
View File
@@ -30,6 +30,7 @@
"individuals": 400,
"generations": 400,
"seed": null,
"fitness_cache_max_entries": null,
"measurement_max_age_seconds": 300,
"tail_horizon_hours": 48,
"terminal_value_mode": "AUTO",
@@ -68,6 +69,7 @@
"individuals": 400,
"generations": 400,
"seed": null,
"fitness_cache_max_entries": null,
"measurement_max_age_seconds": 300,
"tail_horizon_hours": 48,
"terminal_value_mode": "AUTO",
@@ -173,6 +175,7 @@
| Name | Type | Read-Only | Default | Description |
| ---- | ---- | --------- | ------- | ----------- |
| fitness_cache_max_entries | `Optional[int]` | `rw` | `None` | Maximum number of keys in the per-run fitness cache. None = unbounded (default), 0 = cache disabled, N > 0 = keep at most N keys and evict the oldest first. Every cached evaluation takes one or two keys. The cache only saves repeated evaluations; the result for a fixed seed is the same with any value. Limit it to cap memory on small devices. |
| generations | `Optional[int]` | `rw` | `400` | Number of generations to evolve [>= 10]. Defaults to 400. |
| horizon | `int` | `ro` | `N/A` | Number of optimization steps. |
| horizon_hours | `int` | `rw` | `24` | The general time window within which the energy optimization goal shall be achieved [h]. Defaults to 24 hours. |
@@ -202,6 +205,7 @@
"individuals": 300,
"generations": 400,
"seed": null,
"fitness_cache_max_entries": null,
"measurement_max_age_seconds": 300,
"tail_horizon_hours": 48,
"terminal_value_mode": "AUTO",
@@ -230,6 +234,7 @@
"individuals": 300,
"generations": 400,
"seed": null,
"fitness_cache_max_entries": null,
"measurement_max_age_seconds": 300,
"tail_horizon_hours": 48,
"terminal_value_mode": "AUTO",
+15
View File
@@ -175,6 +175,21 @@ The behavior of the genetic algorithm can be customized using the following conf
A fixed seed to ensure reproducibility. Runs with the same seed and configuration will
produce the same results.
- **fitness_cache_max_entries** (`int` or `null`, default: `null`):
Limits the fitness cache of one optimization run. The cache remembers the fitness of every
evaluated plan so that a repeated plan is not simulated again. It is cleared after each run,
but during a run it grows with individuals × generations (roughly 100 MB at 300 × 400) while
typically only 5–15 % of the evaluations hit it.
- If `null`, the cache is unbounded (previous behaviour).
- If `0`, the cache is disabled; every plan is simulated.
- If a positive integer N, the cache holds at most N keys and drops the oldest first. Each
evaluated plan takes one or two keys.
The value never changes the result: with a fixed seed, all settings give the same plan. Small
devices (e.g. 512 MB RAM) should use `0` or a few thousand; this costs a few percent of run
time.
- **penalties** (`dict`):
Defines how penalties are applied to solutions that violate constraints (e.g., undercharged
batteries). Penalty function parameter values influence the fitness score, discouraging