Hi, we are currently focusing on optimizing our game and when I profiled it I sometimes get this “Incremental purge collection”. Just wonder what it is? Is there a way to get more information from the trace? When it happens, it’s over several frames and causing big hitches.
[Image Removed]
[Image Removed]
regrads,
Alex
[Attachment Removed]
Steps to Reproduce
It’s not a bug I believe. Would just love some help to understand it.
[Attachment Removed]
Hello,
It appears that one of the objects being destroyed is causing the flush of the rendering commands. You could try making a new capture with -statnamedevents which you had more events. That might show which class is responsible to for the flush. An alternative would be to use SuperLuminal which is sampling profiler. It would directly show the call stack that lead to the flush.
Feel free to share your profiling data for review.
Regards,
Martin
[Attachment Removed]
Hi Martin,
Pretty sure I was already using named events in the screenshots.
Thanks a lot for the tip of SuperLuminal, I didn’t know about it. It’s pretty amazing.
I checked it out and there I can see it’s from PCG, how can it be this big? [Image Removed]
Regards,
Alex
[Attachment Removed]
Hi,
Have you tried digging under the destructor of FPCGMetadataAttribute? I’m guessing it might be related to the destruction of the Values member (TArray) and some interactions with the memory allocators. I suspect this is a different case from the Insights capture as I would be surprised if this is the source of the Rendering commands flush.
Re: named events. It’s possible that the Object causing the flush doesn’t generate them. Adding more channels might be useful but Superluminal is probably the fastest option
Martin
[Attachment Removed]
Hi!
I’m so sorry, you are absoloutely correct, that’s the wrong one.
I was able to reproduce it again. Unfortunetaly it doesn’t tell me much.
Maybe you have a better idea what’s going on.
[Image Removed]
Alex
[Attachment Removed]
Do you have the caller for FlushRenderingCommand? The top of the stack would be needed to find the class that causes it.
[Attachment Removed]
ah, yes!
From the skeletalmesh it seems.
[Image Removed]
[Attachment Removed]
The flush that you are seeing in USkeletalMesh::ReleaseResources only happens in the editor builds. Not sure why I haven’t noticed this was from the Editor earlier. The GC patterns are much different from the cooked game because of the unoptimized data format and others. You should not care to optimize the GC times in that context (even when running with -game).
The non-editor builds have some optimizations that help reduce the cost of the GC. The main difference is the “disregard” list of objects which basically contains the CDOs and the assets loaded during the initialization phase of the engine. Those objects are considered permanent and the GC code ignores then until the final run when closing the process.
I recommend adding -NOVERIFYGC as a launch argument when profiling the Development and Test targets. This prevent some costly validation code from running. The validation is not present in a Shipping target.
Regards,
Martin
[Attachment Removed]
I should have mentioned Editor, sorry!
Did not know about the command. Thank you, I’ll use it in the future.
Thanks for your help!
Regards,
Alex
[Attachment Removed]