O9 valide en jeu : chargement de partie 71 s -> 22,5 s, physique 463 -> 313 Mo

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
edujiro5972 2026-10-02 08:32:50 +02:00
parent 8abf1d4ad8
commit de4b8f2097

View file

@ -296,4 +296,25 @@ Pistes, par ordre de risque :
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 ?
Question préalable (protocole §3.1) : le chargement d'une partie prend-il aussi environ une minute en 4.27 ?
### 12.1 Correction appliquée et résultat (option 1, décision utilisateur)
Commandlet `LPSetComponentCollision` : composants `Tree` et `Car` de `MapMarkers` en `NoCollision` (CHG-062). Diff
`LPDumpAssets` avant/après : 2 lignes. Les composants `HISM_C` des bâtiments, ajoutés à la volée, gardent leur
collision. Build `LifePlay_Build_5.5_O9`, validé en jeu le 2026-10-02 : chargement plus court, arbres et voitures
toujours affichés. Tag `O9-valide`.
| Mesure (trace Insights et LLM) | Avant | Après |
|---|---:|---:|
| Bouton « Continue » jusqu'à la partie jouable | **71,1 s** | **22,5 s (−68 %)** |
| `GenerateTrees` (par appel) | 15,4 s | 0,3 s |
| Chargements bloquants (`TickAsyncLoading GT`, plus long) | 10,5 s | 1,3 s |
| Mémoire physique (Chaos) | 463 Mo | **313 Mo (−150 Mo)** |
| Mémoire totale du processus | 3 546 Mo | 3 324 Mo |
Les deux sessions ont des durées différentes : les chiffres de mémoire sont indicatifs ; les durées de fonctions sont
directement comparables.
Reste : `ActualSpawnMarkers` prend encore **15 s**. Il ajoute ≈ 80 000 instances aux composants `HISM_C` des bâtiments,
avec ≈ 49 500 corps physiques. Une piste O9b serait d'en couper la collision, si elle ne sert pas aux clics (à vérifier).