LifePlay-Revival/Docs/Migration/etat/ST/STE/STE-H4-MESURE.md

STE-H4-MESURE : mesure en jeu des saccades (archive STE-J5, HEAD 4283c13) — 2026-10-11

Décision de l'utilisateur : « Mesurer d'abord en jeu » (Q-H4-5) ; demande de l'utilisateur : automatiser la mesure. Fenêtre « mesure » de Big Boss (MACHINE CALME, réserve active jusqu'au signal de fin, envoyé à la fermeture du jeu).

1. Protocole appliqué

Lancement par l'utilisateur (le mode automatique a refusé le lancement par l'orchestrateur) : & "D:\Game\LifePlay_Build_5.8_STE-J5_Development\Windows\LifePlay.exe" -csvGpuStats -llm -llmcsv '-ExecCmds=csvprofile repeat=20, csvprofile frames=9000' (options du lanceur LifePlay_debug_sessionC_profil.bat de l'archive). Parcours : comme J5 (lieu peuplé, scènes avec la compagne, repos). Aucune commande console. Sorties (...\STE-J5_Development\Windows\LifePlay\Saved\) : Logs\LifePlay.log (01:30:21, 4 324 393 o, MD5 8498D5F2…, copie de lecture scratchpad\M-H4-LifePlay.log) ; Profiling\CSV\Profile(20261011_012223).csv et (…012509) (9 000 trames chacune) ; (…012748) interrompue à la fermeture (pas d'en-tête final : colonnes non fiables, écartée) ; Profiling\LLM\LLM_Pid38448_….csv (437 lignes). Un memreport du 01:12:02 (Pid 18480) vient d'un lancement antérieur (hors protocole). Analyse : script Python scratchpad\mesure_h4.py (en-tête CSV en fin de fichier, [HasHeaderRowAtEnd]).

2. Résultats CSV (2 captures valides, 324 s)

Capture	Trames	Durée	FrameTime méd / p99 / max	GameThread méd / p99 / max	≥ 50 ms	dont GameThread ≥ 80 %	FlushAsyncLoading (dans ≥ 50 ms)
012223	9 000	165,5 s	16,7 / 34,3 / 4 342 ms	5,4 / 36,1 / 4 294 ms	68 (14,8 s)	21	215 (28)
012509	9 000	158,6 s	16,7 / 32,9 / 530 ms	5,2 / 32,4 / 529 ms	64 (8,2 s)	18	122 (19)

Lecture : image normale à 16,7 ms (vsync 60 Hz), GPU 7-11 ms et rendu 7-9 ms en médiane : la marge est large ; les pics sont du côté du thread de jeu (Game) ou des chargements synchrones, pas du GPU (max GPU 18,8 ms).

3. Mémoire (LLM)

Total 2 764 → max 3 368 → fin 3 200 Mo ; textures 381 → 677 → 574 Mo ; maillages 70 → 80 → 78 Mo ; animation 18 → 19 Mo ; UObject 152 → 167 → 159 Mo. Aucune croissance continue sur la session (la mémoire redescend) ; maillages et animation stables.

4. Classement des trames ≥ 50 ms du journal (trames consécutives [n], 5 753 trames, 136 longues, 29,6 s)

Classe (contenu de la trame longue)	Trames	Durée	Avec FlushAsyncLoading
Écriture d'une ligne LLM csv (instrument de mesure, dont démarrage 4,3 s)	25	7,8 s	0
SPAWN (apparition de PNJ)	46	5,5 s	38
GenerateRecs (TopRight, juste après une fin de scène : DestroyDummy was from DestroyPerson ou CumOn Clear)	13	4,9 s	0
FlushAsyncLoading seul	21	4,5 s	21
Démarrage / chargement	1	3,2 s	0
Autres	22	3,1 s	0
CHECKING:	8	0,7 s	0

Autres comptes : index SPAWN 95, DESTROY 90, FlushAsyncLoading 422, No SkeletalMesh 13 639, UNHIDE Persons 17, GI_C:Dress: 0, compagne moves to 19, Fatal 0.

5. Conclusions (établi sur cette mesure, sauf mention)

• Fin de scène (« saccades » restantes vues par l'utilisateur) : 13 trames de 300 à 450 ms, chacune juste après la fin d'une scène, toutes avec [TopRight_C] GenerateRecs (génération des recommandations du panneau en haut à droite). Cause probable : TopRight.GenerateRecs (estimé : coïncidence systématique, coût non profilé par fonction) → fiche H8.
• Apparition des PNJ : 46 trames SPAWN dont 38 avec FlushAsyncLoading, plus 21 FlushAsyncLoading seuls : chargements synchrones d'assets de personnage (≈ 10 s sur 324 s) → fiche H7.
• F5 (No SkeletalMesh) : aucune trame longue attribuée (confirme STE-H4-DIAG.md § 3.4) ; C0 reste un nettoyage du journal.
• Mémoire : pas de fuite visible ; la voie B (garder les corps) aurait un coût faible en maillages (78-80 Mo au total) mais n'a pas été retenue.
• Réserve : l'écriture des lignes LLM csv coïncide avec 25 trames longues : -llmcsv perturbe la mesure ; à ne pas utiliser pour départager H7 / H8 (préférer csvprofile seul ou -LPHitchLog).

6. Correction (2026-10-11, après STE-H7-DIAG.md) : décalage d'une trame

Le § 4 attribuait la durée d'une trame au contenu de la trame suivante : l'écart entre le début de la trame n-1 et celui de la trame n mesure la trame n-1 (de même, dans les CSV, FrameTime de la ligne r mesure la trame r − 1, CsvProfiler.cpp:4369-4388, relevé par STE-H7). Recompte corrigé (contenu de la trame n-1), mêmes 136 trames ≥ 50 ms (29,6 s) :

Classe	Trames	Durée	Avec FAL
SPAWN	70	11,2 s	54
Fin de scène (DESTROY, CumOn Clear, DestroyDummy was from DestroyPerson)	14	4,3 s	0
Démarrage / chargement	3	4,5 s	0
FlushAsyncLoading seul	4	3,7 s	4
Autres	24	2,6 s	0
GenerateRecs	8	2,1 s	1
CHECKING:	11	1,1 s	0
Écriture LLM csv	2	0,15 s	0

Conclusions du § 5 corrigées : la saccade de fin de scène se partage entre la trame de fin de scène elle-même (14 trames) et GenerateRecs (8 trames, dont 1 410 ms de TimerManager selon STE-H7) : H8 instruit les deux. L'apparition des PNJ reste la première source (70 trames), mais STE-H7 établit que les FAL n'y pèsent qu'environ 5 % : l'essentiel est du Blueprint relancé par les actions latentes (FlushLatentActions). La réserve sur -llmcsv est levée : 2 trames seulement (0,15 s).