13 KiB
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.CreateGCClustersn'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 gcet le contenu exact deMemReportCommandsne sont confirmés par aucune page 5.6+ ouverte ; la seule source dememreportest 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).