<br>(This is a translation of a [Japanese [Content removed] by Akagi Hibiki.)
Thank you for your continued support.
We perform asynchronous saves using our own implementation On Win64/WinGDK, and UGameplayStatics::AsyncSaveGameToSlot on PS5/XSX. In both cases, we use UGameplayStatics::SaveGameToMemory for the serialization of the save data.
Right after this serialization, the data size increases by approximately 5 to 10 times, and the actual file size of the saved data is close to the size after the serialization. The SaveGameObject, which is an argument of the function, is about 2MB, although there are some differences depending on the platform. The sizes after the serialization on each platform are the followings:
Win64: Approximately 12 to 22 MB
PS5 / XSX: Approximately 22 MB
I would like to know if this increase in data size after the serialization is expected.
Also, if there are configurations or other settings that can avoid this size increase, I would appreciate any information you could provide.
the increase in size for the serialized data is expected.
It’s very likely coming from the serialization via FObjectAndNameAsStringProxyArchive.
This type of archive converts all UObject pointers (8 bytes) to strings, which usually end up several times the size of a pointer, depending on the length of the string/object name.
This will increase the serialized data, especially if the SaveGame object contains a lot of object references.
This is unavoidable since the object name is necessary to uniquely identify the objects when deserializing the savegame again.
I’d recommend to compress the resulting array, the strings in the serialized buffer should allow a good compression ratio.
Unfortunately the SaveGame system does not support compression by default, so you would likely need to do it in your own implementation and wrap the platform specific ones.
You can use Oodle via FCompression::CompressMemory(NAME_Oodle, …) to compress/decompress the TArray returned from the SaveGame API.