LifePlay-Revival/Docs/Migration/etat/OPT/BC/BC-R8.md
edujiro5972 8084622450 LifePlay UE 5.8 : état de développement au 2026-10-19
Tickets : REP1-T4

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-19 22:57:42 +02:00

13 KiB

BC-R8 : mémoire et ramasse-miettes en UE 5.8 (GC, streaming, fuites, références)

Date 2026-10-15, auteur sous-agent Sonnet OPT0-R, 16 entrées : 12 établi / 3 estimé / 1 non vérifié. R10 : +1 entrée(s) établi (R8-101…), voir BC-R10-SOURCES.md.

Remarque : les pages de documentation Epic ouvertes (WebFetch) portent le titre « Unreal Engine 5.8 Documentation » mais aucune date de publication ; la date est donc notée « date inconnue ». Les défauts des cvars ne sont presque jamais donnés par ces pages : ne pas les supposer, les relever dans l'éditeur (console, gc. puis Tab) ou dans Config/BaseEngine.ini.

id affirmation (1-2 phrases, sans copie de texte) source (URL, date, version UE) niveau (établi / estimé / non vérifié) application à LifePlay (système ou fichier) action proposée skill de destination
R8-01 Le GC incrémental répartit l'analyse d'accessibilité sur plusieurs images avec une limite souple par image. Il s'active par gc.AllowIncrementalReachability=1, gc.AllowIncrementalGather=1 et gc.IncrementalReachabilityTimeLimit (exemple 0.002 s), sous [ConsoleVariables] de DefaultEngine.ini. https://dev.epicgames.com/documentation/unreal-engine/incremental-garbage-collection-in-unreal-engine / date inconnue / UE 5.8 établi Config (DefaultEngine.ini) : candidat contre les à-coups périodiques du GC. Défauts non donnés par la page. Mesurer d'abord les à-coups GC (Insights), puis essayer sur une copie de config et comparer ; ne pas activer sans mesure. lp-perf
R8-02 La doc range le GC incrémental comme expérimental, avec une analyse qui peut dépasser la limite de temps, et recommande la prudence avant de livrer avec. https://dev.epicgames.com/documentation/unreal-engine/incremental-garbage-collection-in-unreal-engine / date inconnue / UE 5.8 établi Décision de livraison (config, jeu empaqueté). Traiter comme option d'essai, pas comme réglage par défaut de livraison. lp-perf
R8-03 Pour le GC incrémental, toutes les références UPROPERTY vers des UObject doivent être des TObjectPtr : leurs écritures servent de barrière d'écriture. Sans cela un objet peut être collecté trop tôt. https://dev.epicgames.com/documentation/unreal-engine/incremental-garbage-collection-in-unreal-engine / date inconnue / UE 5.8 établi Code C++ du jeu et de l'addon (membres UPROPERTY en pointeur brut, héritage UE4). Inventorier les UPROPERTY en pointeur brut avant tout essai du GC incrémental ; convertir en TObjectPtr. ue-cpp-build
R8-04 La page précise que le GC incrémental n'est pas entièrement sûr vis-à-vis des threads (objets manipulés hors thread de jeu collectés trop tôt) et le recommande surtout pour des builds mono-thread comme un serveur dédié. https://dev.epicgames.com/documentation/unreal-engine/incremental-garbage-collection-in-unreal-engine / date inconnue / UE 5.8 établi Code C++ qui touche des UObject depuis des tâches asynchrones. Vérifier les accès UObject hors thread de jeu avant essai ; pour un jeu client, rester prudent. lp-perf
R8-05 Conseils d'Epic contre les à-coups GC : budget serré de UObject, pools d'objets, éviter de créer/détruire sans cesse. Moins d'objets réduit la durée d'analyse. https://dev.epicgames.com/documentation/unreal-engine/incremental-garbage-collection-in-unreal-engine / date inconnue / UE 5.8 établi Blueprints qui créent et détruisent beaucoup d'acteurs/composants (PNJ, objets de scène, widgets). Compter les UObject (obj list) par scène ; repérer les classes à fort volume ; envisager des pools. lp-bp-audit
R8-06 Réglages de projet GC : intervalle de purge Time Between Purging Pending Kill Objects, clusters (création, asset, acteur, Blueprint), taille minimale de cluster, GC parallèle, destruction incrémentale/multithread, plafonds d'objets en build cuit. La page ne donne aucun défaut. https://dev.epicgames.com/documentation/unreal-engine/garbage-collection-settings-in-the-unreal-engine-project-settings / date inconnue / UE 5.8 établi Config projet (DefaultEngine.ini, section GarbageCollectionSettings). Relever les valeurs actuelles du projet et les consigner ; ne modifier que sous mesure. lp-perf
R8-07 La doc recommande de garder le plafond de UObject d'un build cuit aussi petit que possible, et signale des vérifications de débogage (FGCObject sans GetReferencerName, UObject qui dérive de FGCObject). https://dev.epicgames.com/documentation/unreal-engine/garbage-collection-settings-in-the-unreal-engine-project-settings / date inconnue / UE 5.8 établi Config projet ; code C++ avec FGCObject. Comparer le nombre réel d'objets (obj list) au plafond configuré ; activer les vérifications Debug en développement. lp-validate
R8-08 Un guide (blog, 2024) liste les remèdes aux pics de GC : moins d'objets, GC manuel pendant un écran de chargement ou une interface plein écran, intervalle plus long avec repli bas-mémoire (gc.LowMemory.TimeBetweenPurgingPendingKillObjects, gc.LowMemory.MemoryThresholdMB), GC avant de décharger un niveau. Un commentaire cite s.ForceGCAfterLevelStreamedOut=0, qui masque le pic au prix de la mémoire. https://larstofus.com/2024/07/21/unreals-garbage-collection-spikes-and-how-to-fight-them/ / 2024-07-21 (commentaires 2025-01) / UE 5.x (version précise non donnée) estimé Blueprints de chargement/déchargement de niveau ; config GC. Déclencher un GC explicite aux moments de transition (écran de chargement) ; mesurer l'effet sur le pic. lp-perf
R8-09 Le streaming de textures se règle par r.TextureStreaming, r.Streaming.PoolSize (Mo ; 0 = illimité ; le pool contient aussi UI, NeverStream, cubemaps), r.Streaming.UseFixedPoolSize, r.Streaming.LimitPoolSizeToVRAM, r.Streaming.MaxEffectiveScreenSize, r.Streaming.MipBias, r.Streaming.Boost. https://dev.epicgames.com/documentation/en-us/unreal-engine/texture-streaming-configuration-in-unreal-engine / date inconnue / UE 5.8 établi Config rendu (DefaultEngine.ini / Scalability) ; le projet est en SM5. Relever les valeurs du projet, vérifier que le streaming est actif et que le pool est borné pour le matériel visé. lp-perf
R8-10 La doc liste aussi r.Streaming.HLODStrategy, r.Streaming.FullyLoadUsedTextures (garde en résidence à pleine résolution, coûteux), r.Streaming.UseAllMips (réservé aux démonstrations) et r.Streaming.DropMips (débogage). https://dev.epicgames.com/documentation/en-us/unreal-engine/texture-streaming-configuration-in-unreal-engine / date inconnue / UE 5.8 établi Config rendu : vérifier qu'aucun de ces cvars de démonstration n'est resté actif. Chercher UseAllMips / FullyLoadUsedTextures dans les ini et les Blueprints de console. lp-validate
R8-11 Réponse d'un employé Epic (ancienne, Answers) : passer le pool de 200 à 4000 a fait grimper fortement la mémoire ; mieux vaut une hausse modeste après diagnostic. Version et date non données. https://answers.unrealengine.com/questions/374086/view.html?sort=votes / date inconnue / UE 4.x (non confirmé en 5.6+) ; vue dans un résultat de recherche, page non ouverte estimé Config rendu (pool de textures). Ne pas gonfler r.Streaming.PoolSize sans mesure de la demande réelle. lp-perf
R8-12 Le LLM (Low Level Memory Tracker) se lance avec -LLM ; -LLMCSV écrit un CSV (Saved/Profiling/LLM, une ligne toutes les 5 s par défaut, LLM.LLMWriteInterval). Commandes stat LLM, stat LLMFULL, stat LLMPlatform, stat LLMOverhead ; options expérimentales -llmtagsets=Assets et AssetClasses (compilation avec LLM_ALLOW_ASSETS_TAGS). Compilé hors des builds Shipping. https://dev.epicgames.com/documentation/en-us/unreal-engine/using-the-low-level-memory-tracker-in-unreal-engine / date inconnue / UE 5.8 établi Procédure de mesure mémoire (build Development ou éditeur autonome). Définir une procédure LLM + CSV rejouable pour comparer deux versions. lp-perf
R8-13 Memory Insights : lancer avec -trace=default,memory dès le démarrage (pas de connexion tardive) ; ajouter metadata,assetmetadata pour attribuer par asset/classe. L'onglet Investigation avec marqueurs A/B/C et la règle « Memory Leaks » trouve ce qui est alloué entre A et B et jamais libéré après C, utile pour un changement de niveau. Callstacks et symboles (pdb) sur Win64. https://dev.epicgames.com/documentation/en-us/unreal-engine/memory-insights-in-unreal-engine / date inconnue / UE 5.8 établi Détection de fuites à la transition entre niveaux ; build Development avec symboles. Écrire une procédure « aller-retour de niveau » avec marqueurs A/B/C. lp-perf
R8-14 memreport (et -full) écrit un fichier texte qui regroupe la sortie des commandes de BaseEngine.ini (dont obj list) ; méthode d'Epic : deux rapports avant/après puis diff texte, et obj refs name=<asset> shortest pour trouver qui retient un asset. L'usage de obj gc avant le rapport n'est pas dans la source : hypothèse de ma part. https://www.unrealengine.com/en-US/blog/debugging-and-optimizing-memory / 2014-10-29 / UE 4.x (non confirmé en 5.6+) ; vue dans un résultat de recherche, page non ouverte estimé Procédure de chasse aux fuites (console en jeu, hors Shipping). Vérifier en 5.8 les sections de MemReportCommands et la syntaxe de obj refs / obj gc avant d'écrire la procédure. lp-perf
R8-15 World Partition : les cellules de grille (exemple 256 m) se chargent autour des sources de streaming dans le rayon Loading Range (exemple 768 m) ; plusieurs grilles peuvent nuire aux performances ; existent wp.Runtime.OverrideRuntimeSpatialHashLoadingRange, wp.Runtime.MaxLoadingLevelStreamingCells, wp.Runtime.HLOD 0. La page ne donne pas de chiffres de mémoire. https://dev.epicgames.com/documentation/en-us/unreal-engine/world-partition-in-unreal-engine / date inconnue / UE 5.8 établi Niveaux du jeu s'ils sont ou seront en World Partition ; HLOD ; Data Layers. Vérifier si les cartes utilisent World Partition ou le streaming de niveaux classique ; si oui, relever grille, portée, HLOD. lp-perf
R8-16 Références dures et souples : une référence dure charge la cible avec son propriétaire (risque de tout charger au démarrage) ; TSoftObjectPtr ne retient pas l'objet contre le GC, il faut un chargement asynchrone puis une référence forte pendant l'usage. Reference Viewer et Size Map aident à voir ce qui est tiré en mémoire. https://dev.epicgames.com/documentation/unreal-engine/referencing-assets-in-unreal-engine et https://dev.epicgames.com/documentation/unreal-engine/asynchronous-asset-loading-in-unreal-engine / date inconnue / UE 5.x ; vues dans des résultats de recherche (synthèse), pages non ouvertes non vérifié Blueprints (variables de classe/asset en référence dure, Cast vers de grosses classes, Data Assets chargés d'avance). Auditer les références dures des Blueprints centraux (GameInstance, mode de jeu, widgets principaux) avec Reference Viewer et Size Map. lp-bp-audit
R8-101 Les notes 5.8 ajoutent World Partition Insights : outils de débogage du chargement dynamique de World Partition dans Unreal Insights et dans l'éditeur (expérimental). Les notes 5.6 à 5.8 ne mentionnent aucun nouveau réglage du ramasse-miettes (recherche de Garbage Collect : seulement des correctifs sans lien). https://dev.epicgames.com/documentation/unreal-engine/unreal-engine-5-8-release-notes / date inconnue (lue 2026-10-15) / UE 5.8 établi Diagnostic du streaming de monde et de la mémoire pendant les parcours. Utiliser World Partition Insights si le monde est partitionné. lp-perf

Lacunes et doutes

  • Aucun défaut de cvar n'est donné par les pages Epic ouvertes ; gc.CreateGCClusters n'est pas confirmé comme nom de cvar (la doc parle du réglage de projet « Create Garbage Collector UObject Clusters »). Rien de fiable trouvé sur l'effet réel des clusters en 5.6 à 5.8.
  • Time Between Purging Pending Kill Objects : définition confirmée (secondes de temps de jeu), défaut non confirmé en 5.8 (60 s dans des sources anciennes).
  • Des pages du suivi de bugs Epic (UE-223522 : blocage avec écran de chargement ; UE-386406 : surcoût des barrières même désactivé) sont apparues dans les résultats mais n'ont pas été ouvertes : non vérifié, à lire sur issues.unrealengine.com avant toute décision sur le GC incrémental.
  • stat streaming, listtextures, obj gc et le contenu exact de MemReportCommands ne sont confirmés par aucune page 5.6+ ouverte ; la seule source de memreport est de 2014.
  • World Partition : aucune page ouverte sur le coût mémoire ni sur les valeurs recommandées de cellule/portée.
  • Aucune note de version 5.6 à 5.8 consultée sur le GC ou le streaming ; les entrées d'Epic datent donc seulement de « doc 5.8, date inconnue ».
  • Entrées les moins sûres : R8-16 (pages non ouvertes) et R8-14 (source de 2014).