ErControl

Beobachtung¶

Während eines laufenden Trainings (auch im Simulationsmodus ohne Pulsmesser, mit der veröffentlichten 3.1.7) bleibt ein Fenster beim Verschieben jede Sekunde kurz stehen. Der UI-Thread wird vom Trainings-Tick blockiert.

Messung im Tick (Datenbank auf einem Netzlaufwerk): Speichern 200 bis 430 ms, Vorlauf bis zu den Diagrammen 94 bis 235 ms. Mit lokaler Datenbank sind es 20 bis 35 ms pro Tick, davon etwa 10 bis 18 ms vor den Diagrammen.

Ursache¶

Prefs hatte keinen Cache. Jedes Lesen einer Einstellung hat

• per Reflection über alle Properties der Klasse nach dem Attribut gesucht,
• ChangeTracker.Entries() durchlaufen (löst DetectChanges über alle verfolgten Entitäten aus, im Training auch über alle TrainingPoints),
• und für nie gesetzte Einstellungen (es gilt der Standardwert) jedes Mal eine Datenbankabfrage gestellt.

Der Tick liest pro Sekunde mehrere Einstellungen (UseOnlyPCMode, RecoveryPulseMeasurement, ErgoType, Cr, CwA, EfficiencyFactor, bei Gangschaltung die Automatik-Grenzen). Auf einem langsamen Datenträger kostete jede nicht gesetzte Einstellung einen Zugriff.

Umgesetzt¶

• Das Attribut je Property wird nur einmal per Reflection gesucht.
• Gelesene Einstellungen werden je Schlüssel und Benutzer in der Prefs-Instanz gemerkt (dieselben verfolgten Entitäten wie zuvor). Ein Schreiben und RollbackChanges halten den Cache aktuell bzw. leeren ihn.
• Eine nicht vorhandene Einstellung wird nur 10 Sekunden gemerkt, damit eine von einer anderen Prefs-Instanz angelegte Einstellung bald sichtbar wird.

Nicht Teil dieses Tickets¶

Das Speichern des Trainingspunkts in jedem Tick (SaveChanges, auf dem UI-Thread) und die Diagrammaktualisierung bleiben. Bei lokaler Datenbank kosten sie zusammen 20 bis 30 ms pro Tick.