edujiro5972/LifePlay-Revival
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

O9 : trace Insights, chargement de partie de 71 s du aux 160 916 arbres de la carte avec collision

Browse source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
edujiro5972 2026-10-02 08:14:55 +02:00
parent 56dba20af8
commit 0ae5e29915
1 changed files with 36 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
Docs/Migration/11_Audit_Optimisation.md
View file

@ -261,4 +261,39 @@ Piège : la cuisson incrémentale (`-iterate`) garde le contenu déjà cuit des
| Paquets du jeu | 8 561 | 8 561 |
| `NNE`, `Interchange`, `.pdb`, `DirectML.dll` | présents | absents |
Build : `D:\Game\LifePlay_Build_5.5_O1`. **Validé en jeu le 2026-10-02** (« pas de soucis rencontrés »), tag `O1-valide`.
Build : `D:\Game\LifePlay_Build_5.5_O1`. **Validé en jeu le 2026-10-02** (« pas de soucis rencontrés »), tag `O1-valide`.
## 12. Lot O9 : trace Unreal Insights (2026-10-02)
Trace courte (≈ 4 min, 841 Mo, `-trace=cpu,frame,bookmark,loadtime -statnamedevents`), analysée en ligne de commande :
`UnrealInsights.exe -OpenTraceFile=… -AutoQuit -NoUI -ExecOnAnalysisCompleteCmd="@=export.rsp"` avec
`TimingInsights.ExportTimerStatistics … -threads=GameThread`. Résultats : `D:\Game\LifePlay_Backup_5.5\O9`.
> Pièges : chemins avec `/` (les `\` sont lus comme des échappements) ; une trace de 10 minutes (3,3 Go) demande
> plus de 50 Go de mémoire à l'analyse, et Insights s'arrête quand on ferme son avertissement de mémoire.
**Constat principal : le chargement d'une partie (« Continue ») prend 71 s**, dont :
| Fonction (thread de jeu) | Durée | Détail |
|---|---:|---|
| `PC.AutoLoad` → `GI.loadgame` | 60,8 s | — |
| `MapMarkers.SpawnMapMarkers` (3 appels) | 59,9 s | `MoveCity` 29,4 s ; `ActualSpawnMarkers` 29,2 s |
| `MapMarkers.GenerateTrees` / `GenerateHISM` | 28,8 s | — |
| `HISMC_AddInstance` | **54,8 s** pour 160 916 appels | arbres de la carte ajoutés un par un |
| `FChaosScene::AddActorsToScene`, `Init Body` | 161 272 appels | **un corps physique par arbre** |
| `TickAsyncLoading GT` (chargements bloquants) | 19,8 s | dont 10,5 s pour l'instance de jeu au démarrage |
| `LoadTxt` | 8,0 s pour 1 413 appels | lecture des fichiers texte, répartie dans la partie |
Cause : les composants `Tree` et `Car` de `MapMarkers` (`HierarchicalInstancedStaticMeshComponent`) gardent la
collision par défaut (`BlockAll`). Chaque arbre de la carte (≈ 160 000) reçoit donc un corps physique Chaos. Cela
explique probablement aussi la **physique à 463 Mo** mesurée en §9.3. En jeu, hors chargement, le thread de jeu reste
léger : il est inactif la moitié du temps (`Game thread idle time`).
Pistes, par ordre de risque :
1. Couper la collision des arbres et des voitures de la carte (`NoCollision`) : chargement et mémoire fortement
réduits. Cela change le comportement si le joueur doit être bloqué par les arbres sur la carte de la ville
(**à confirmer par l'utilisateur**).
2. Garder la collision, mais ne la créer qu'une fois tous les arbres ajoutés (sous-système C++ : collision coupée
pendant `GenerateTrees`, puis rétablie). Le gain porte sur le temps seulement, pas sur la mémoire.
Question préalable (protocole §3.1) : le chargement d'une partie prend-il aussi environ une minute en 4.27 ?