Why does Profiler.GetRuntimeMemorySize return larger values for textures?

I’m using the Profiler.GetRuntimeMemorySize function to output a list of textures loaded in a level for diagnostic purposes. I’ve noticed that the value it reports is different from the size value shown in the import settings. For example, I have a texture whose import settings say it is 2.7MB, but the profiler is telling me that the texture is 3.3MB.

Can anyone give some insight into why that would be the case? I guess that the in-memory representation of the texture is larger than its on-disk representation. But why exactly? The texture doesn’t have Read/Write enabled, which is the only settings I’ve heard that would cause a texture to take up more space in memory.

Also, is it safe to trust the profiler memory function output in the editor?

It would appear that the texture output from Profiler.GetRuntimeMemorySize in the editor is not accurate. If I run the same scene in editor and on device, I can see that the texture on device is the expected size, while its size is bloated in the editor. This doesn’t seem to be a problem for other asset types (like Audio, Meshes).

The main reason I am using this function is to run unit tests on my levels in the editor, to ensure that the sizes of assets are reasonable before creating a build. Because of the inaccuracy of GetRuntimeMemorySize with textures, I can’t use it for this purpose.

My alternate solution is to use an approximate calculation of texture memory while in the editor. Rather than using GetRuntimeMemorySize, I can approximate the in-memory filesize pretty well with this calculation:

TextureMemoryBytes = (width * height * bitsPerPixel) / 8.0f

One final consideration is that you’d want to multiply the size by 1.33 if mipmaps are used (mipmaps add ~33% to file size).

  1. The size given in the preview under the import settings is the SIZE ON DISC, not the size in Memory
  2. The API can’t predict how your import settings will affect the RAM and VRAM impact on the targeted platform and will only ever give you the size that it currently takes on the running platform, in this situation
  3. Textures are always loaded Read/Write enabled in the Editor as the Editor needs to be able to read them for Editor purposes.

So: Only ever profile this on device or you’ll get the wrong data and are likely to misinterpret it.