What is the purpose of the File Read Buffer(s) in Addressable Metadata?

[SonicBloomEric]

I’ve been reading the latest Unity blog entry and it has this curious statement:

There is a SerializedFile entry in memory for each loaded AssetBundle. This memory is AssetBundle metadata rather than the actual assets in the bundles. This metadata includes:

• Two file read buffers
• A type tree listing every unique type included in the bundle
• A table of contents pointing to the assets

Of these three items, file read buffers occupy the most space. These buffers are 64 KB each on PS4, Switch, and Windows RT, and 7 KB on all other platforms. In the above example, 1,819 bundles * 64 KB * 2 buffers = 227 MB just for buffers.

The Addressables documentation further states this:

When Unity loads an AssetBundle, it allocates an internal buffer for each serialized file in the AssetBundle. This buffer persists for the lifetime of the AssetBundle. A non-scene AssetBundle contains one serialized file, but a scene AssetBundle can contain up to two serialized files for each scene in the bundle. The buffer sizes are optimized per platform. Switch, Playstation, and Windows RT use 128k buffers. All other platforms use 14k buffers.

Ignoring the 1-vs-2 buffer counting difference here, neither of these documents explains why those file “read buffers” need to be allocated, let alone kept alive. Does anyone have any insight as to what those are for?

[Jonas-Neuston]

Yeah, I’d really want to know that as well. What are they for? We’re seeing a significant memory footprint of SerializedFile when using Addressables. We have tens of thousands of SerializedFile entries and they take up several hundreds of MB but we only have two bundles. With the lack of documentation around this it’s very hard to know what’s going on and how to get rid of it.

[shelllee]

read buffer and decompress buffer？not exactly…