PERF.TEX001

Read/Write Enabled keeps a second copy of every texture in RAM

Warning Performance One-click fix (Pro)

Read/Write Enabled (TextureImporter.isReadable) tells Unity to keep the decoded pixel data in CPU memory in addition to uploading it to the GPU. The texture is then counted twice: once in graphics memory, once in managed/native heap. For a 2048×2048 RGBA texture that is a few megabytes you’re paying twice for, per texture.

What the scan looks at

Every texture importer in the project whose largest dimension is 512 px or more and that has Read/Write Enabled ticked. Small icons are skipped — the flag is equally pointless there, but the memory is not worth a finding.

Why it costs you

The GPU copy is what renders. The CPU copy exists only so scripts can call GetPixels, SetPixels, GetRawTextureData, Texture2D.Apply, EncodeToPNG, or read the texture back for collision/heightmap-style logic. If nothing in your project does that to a given texture, the second copy is pure waste that ships in the build and stays resident at runtime.

It is easy to enable by accident: some importer presets have it on, and it silently survives every later change to compression or max size.

How to fix it by hand

In the Inspector for the texture, under Advanced, untick Read/Write Enabled, then reimport. Before you do, search your code for CPU-side reads of that texture:

// These need Read/Write Enabled:
tex.GetPixels();  tex.GetPixels32();  tex.SetPixels(...);  tex.Apply();
tex.GetRawTextureData();  tex.EncodeToPNG();  ImageConversion.EncodeToJPG(tex);

Common legitimate cases: terrain heightmap sampling, runtime texture painting, minimap/screenshot compositing, and some third-party plugins that decode into an existing texture. If you only read pixels once at load time, consider doing that read in the editor instead and baking the result — then the flag can go.

What PerfLint does about it

The scan lists every texture that trips the rule with its estimated memory saving, so you can sort by what’s worth doing. Pro can flip the flag off from the finding row, one texture or the whole group at a time — it’s an import setting change, so it’s reversible and Unity reimports the asset for you.

When to ignore it

If a texture genuinely feeds a CPU-side read path, leave it alone. The rule is a Warning rather than a Critical for exactly this reason: the scan can see the flag, but it can’t see whether some GetPixels call three assemblies away depends on it.

Check your own project. The scan is free, runs entirely on your machine, and reports this rule with the exact assets that trip it — nothing is uploaded.

Install the free scanner See a sample report


Last reviewed · All rules