[Performance] isEligible re-filtert/sortiert die ganze History pro Kandidat #9

New Issue

2026-06-03T14:10:02+02:00

ferdi2go commented

2026-06-03 14:10:02 +02:00

Schweregrad: LOW–MEDIUM

Dateien: js/algorithm.js:49-57

Problem: Pro Tag × pro Mitarbeiter wird [...history, ...monthAssignments] neu erzeugt, gefiltert, gemappt und sortiert → O(Tage·Mitarbeiter·History). Bei ~20 MA/22 Tagen unkritisch, skaliert aber schlecht.

Fix: lastDate/Counts pro Mitarbeiter einmalig vor der Tagesschleife vorberechnen (Map).

**Schweregrad:** LOW–MEDIUM **Dateien:** `js/algorithm.js:49-57` **Problem:** Pro Tag × pro Mitarbeiter wird `[...history, ...monthAssignments]` neu erzeugt, gefiltert, gemappt und sortiert → O(Tage·Mitarbeiter·History). Bei ~20 MA/22 Tagen unkritisch, skaliert aber schlecht. **Fix:** `lastDate`/Counts pro Mitarbeiter einmalig vor der Tagesschleife vorberechnen (Map).

ferdi2go added the severity/low performance labels 2026-06-03 14:10:02 +02:00

ferdi2go commented

2026-06-03 14:44:45 +02:00

Behoben in c076b5e: histCount-Map einmal pro Generierung vorberechnet — scoreCandidate macht jetzt O(1)-Lookup statt History-Scan pro Kandidat. minGap ermittelt das letzte Datum per Single-Pass-Max statt Array-Spread + .sort(). Verhalten unverändert (alle Tests grün). Bewusst keine riskante inkrementelle Umstrukturierung des Scheduling-Kerns bei aktueller Skala.

Behoben in `c076b5e`: `histCount`-Map einmal pro Generierung vorberechnet — `scoreCandidate` macht jetzt O(1)-Lookup statt History-Scan pro Kandidat. minGap ermittelt das letzte Datum per Single-Pass-Max statt Array-Spread + `.sort()`. Verhalten unverändert (alle Tests grün). Bewusst keine riskante inkrementelle Umstrukturierung des Scheduling-Kerns bei aktueller Skala.

ferdi2go closed this issue

2026-06-03 14:44:46 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: ferdi2go/Meeting-Mixer#9