I have some huge bars on my profile.
It seems that the garbage collector causes them.
I’m not destroying objects created by me.
Maybe it’s related to particles system (but I have them in the pool for recycling).
Sot I have no idea what garbage it’s cleaning… maybe it’s "internal engine stuff.
In any case those bars are huge…
Any ideas to smooth that?
Thank you so much!!
Any pointers that you set to nullptr will be marked as pending kill and will wait for the GC to become fully invalidated and their memory cleaned up.
If this is the start of a level after switching from a main menu then perhaps the GC is cleaning up the old level at the beginning?
Niagara has it’s own pooling system internally so it will probably reserve memory for it’s own particles & reuse them.
It seems the spikes in garbage collection could be due to unreferenced objects or scene transitions, particularly if they’re from previous levels. Ensure your particle system pools are efficiently managing instances and check for non-particle temporary data. Optimizing data handling at level transitions might also reduce these spikes.
Hi @3dRaven and @Randy_Seth
I only have four pointers set to nullptr (they are FRunable threads) they are destroyed right at the end of everything (in the EndPlay() function of the AAIController).
In the bars at the beginning it is not the case… I am running the map in standalone mode, without running menus beforehand. But it happens in the bars at the end… effectively at the end it is traveling to the main menu.
@echo off
cd %~dp0
cd..
cd..
set EDITOR="C:\Program Files\Epic Games\UE_5.5\Engine\Binaries\Win64\UnrealEditor.exe"
set PROJECT="%cd%\Catharsis.uproject"
set MAPPATH="/Game/Game/Maps/GamePlay/Arena01/L_Arena01"
set "RUNASSERVER=%MAPPATH% -server -port=7777 -log"
set "CPUTRACE=-cpuprofilertrace -loadtimetrace"
set "RUNASCLIENT=127.0.0.1:7777 -game -windowed -log -resx=1000 -resy=500 -winx=100 -winy=100"
:: start "" "C:\Program Files\Epic Games\UE_5.5\Engine\Binaries\Win64\UnrealEditor.exe" "%cd%\Catharsis.uproject" %MAPPATH% -game -windowed -log -resx=1000 -resy=500 -winx=100 -winy=100 -client
start "" %EDITOR% %PROJECT% %RUNASSERVER% %CPUTRACE%
start "" %EDITOR% %PROJECT% %RUNASCLIENT%
pause
What happens at the beginning I think may be due to this.
The first bar is because of a python script (I’m not using python so it must be something in the engine).
The Second bar is the Garbage Collector and FlushAsyncLoading…
The garbage collector has a very large CPU time, but FlushAsyncLoading CPU time is almost infinite. (I need to check this… I think a material is causing problems here).
Then the GC is doing a Perform Reachability Analysis (It takes a lot of CPU time too).
Then this happen (WinPumpMessage) Huge bar…
Then the GC is doing a another Perform Reachability Analysis in the meadle of the graph (This time the bar is smaller than the previous one… but it is still big)).
And again a few frames ahead
And another WinPumpMessage
So it seems that what causes most of the spikes at the beginning, middle, and end of the graph is the following.
-Perform Reachability Analysis
-WinPumpMessage
I’m using this flag
PoolingMethod = ENCPoolMethod::ManualRelease;
It allows me to have a valid reference of the Niagara component (I hope it to use a pool internally too).
I guess I’m doing it that way… all my particle systems are created at the beginning and destroyed at the end… halfway through they are reused (objects pooling).
Ok, this is new to me… I don’t know what you mean… I’ll look into it.
*Maybe there is a way to configure “Perform Reachability Analysis” to be more frequent?
-Perhaps if analysis is more frequent then there are fewer things to analyze and therefore less time to do them. (It’s just a guess)…
*Looking for solution for WinPumpMessage too…
I guess I’ll have to try it on the compiled and packaged version.
Unless there is a way to disable the debugging system.
Maybe I can do that with a console command?
Thank you very much for the help @3dRaven and @Randy_Seth
