Unity Editor cache folder leak. (Ran out of space on disk)

[zezba9000]

So was doing some Android builds & got an error that my hard-drive space was gone.
The library cache folder took up over 100+ GB of space. And this is for a small custom SRP dev proj.

Unity 2020.3.9
Windows 10

[zezba9000]

After cleaning the library folder and doing some more Android builds here are the file/folder sizes.
Most notable are “Artifacts” & “ShaderCache”.

[zezba9000]

So “ShaderCache” seems to be where its probably at.
Its size increased over a 1.5 GB for a new build with little to no changes. Seems like if I have more shader changes this also increases each build even more as those would increase at least over 2gb each build if not more.

[Joe-Censored]

The ShaderCache issue was supposed to be fixed in 2020.3.1

Unity IssueTracker - Shader error db grows on each build

If you previously had the project on 2020.3.0 or earlier, I’d close Unity, delete the ShaderCache folder, and let Unity recreate it. See if the issue improves. If not, you may have encountered a regression which needs to be reported.

[zezba9000]

@Joe-Censored

'd close Unity, delete the ShaderCache folder, and let Unity recreate it. See if the issue improves.

Thats the first thing I did & considering I had Zero-GB free kinda had too
I actually deleted all cache folders just to be sure.
So sounds like a possible regression. If someone needs the SRP proj on the Unity team I’d be happy to oblige if it helps.

[aleksandrk]

ShaderCache is not only for the error DB, it also contains compiled shader variant cache. If you modify a shader, we don’t delete the variants from the old shader source, as one may want to change it back.
Does it grow if you don’t do any changes to shaders or shader include files and do a build?

[zezba9000]

Doing some clean test builds now. Will post results after.

But regardless of this, the logical solution is to GC unused cache. This is problematic when testing SRP core shader changes. At least an option to enable GC would be nice as 120+ GB of data for a couple shaders is ridiculous when making test builds.

[zezba9000]

So size doesn’t increase if shaders don’t change but as I said before there really should be a GC cleaning up stuff from at least 5 builds ago that weren’t used in the current build.

[aleksandrk]

@zezba9000

the logical solution is to GC unused cache

Definitely

[Juho_Oravainen]

We’ve filed a bug report on this behavior so it will actually get fixed.

Unity IssueTracker - Shader cache grows indefinitely

Thanks for reminding us about this flaw!

[Tensor2]

@aleksandrk

ShaderCache is not only for the error DB, it also contains compiled shader variant cache. If you modify a shader, we don’t delete the variants from the old shader source, as one may want to change it back.
Does it grow if you don’t do any changes to shaders or shader include files and do a build?

My project has about 150gb of actual files (mostly just music). The library folder is 1.7 TB. A bigger SSD will run me $500. Unity’s library folder garbage can go to hell. Ignoring it is not a valid option. Unity is simply not being reasonable. The ShaderCache for my project has passed 150 gb, more than the entire actual project itself.

You need to seriously rework the entire library folder. Put a priority on this. It is not tenable. You are wasting my valuable development time and I cannot even open the project.

[aleksandrk]

@Tensor2 which Unity version do you use? The issue with shader cache growing indefinitely has been fixed a while ago.