Fix FName memory issue when running for extended periods of time
#1423
Conversation
One use for named components is for debugging, specifically when wanting to know what assets are mapped to what you are actually looking at. (thanks @kring for mentioning) Here's how... click on a piece of the terrain in the viewport, try to delete it. You'll see a console message like this...
Is this valuable enough to keep the FName creation around? Probably not. And if debugging in this way, you can just make a test branch, and put the naming back in anyway. Interesting though. |
|
I think this suggestion was made a bit jokingly, but I do think it would be good to wrap this in a define. Something like |
|
@azrogers Sensible suggestion. I've made this change, and it's ready for another look. |
|
Looks good to me. Thanks @csciguy8! |
Closes #1422.
A user reported an error with
FNameallocations when running for long periods of time (5 hours).Interesting output from Unreal
FName overflow, allocated 1024MB of string data. FName strings are never freed and should be created sparinglyIn
loadPrimitiveGameThreadPartwe create a newFNameobject for every primitive loaded. In some cases, these can be fairly large (Ex. 165 characters) as they are essentially the url to the asset that was fetched.This PR solves the problem by avoiding creating an
FNameentirely.Ran through all the samples level and didn't see any issues. Also, these meshes and components are not visible in the Outliner window, so there's no apparent user facing change either.