Is there a way to share the package cache per project?

I noticed when I setup new projects that the folder gets quite large. The two main sources of this size are:

project/Library/Artifacts
project/Library/PackageCache

These use up around 75% of the project size.

Artifacts seems to be a cache for uncompressed assets. This would be preferred as a RAM cache rather than disk, maybe this can be a configurable option and choose to only disk cache some assets like meshes that are smaller.

The package cache has a lot of items that are already in the shared root package cache. The burst package is over 800MB alone and every project has a copy of the same version number.

The shared package cache stores packages with a version number like:

com.unity.burst@1.8.4

The project cache stores without the version number. I have multiple projects with the same burst version and they are stored in each project folder.

Is there a way to move the same version packages to the shared cache?

Nothing in the /Library folder can be shared, and it is not supposed to be shared, and it must be excluded from source control.

This folder contains all sorts of temporary cached data to speed up processing. Some of that data may be machine specific or specific to a user’s preferences. None of the data contained or how Unity uses it is documented.

It is normal for the Library folder to be several times the size of /Assets and it will grow most significantly every time you switch the editor output to a new platform.

You can always delete the Library folder in its entirety and typically also one of its subfolders like PackageCache. Be sure to close the project first. Deleting the Library contents may remove some stale (old or unused platform) data and free up some disk space. But opening the project may take longer initially as (parts of) the Library may be recreated.

No, it’s almost exactly the opposite. It’s all the things Unity generates from your assets. So your Assets folder has a .png, the library has the png after compression, all of it’s mip maps, the metadata about where the sprites are located, etc. etc. Same thing for meshes and animation files and whatnot.

Ie. you need these files in order to do anything! They’re copied to your builds.

Unity maintains a cache of the last 10 gigs of packages you have downloaded in the upm cache. Unity - Manual: Global cache. It also has a copy of those in each project’s Library/PackageCache folder.

Unity could instead skip copying the files into Library/PackageCache and then just share the ones in the upm cache. That would require the upm cache to be of limitless size, though, and cleaning that cache would require knowing about every project on the computer, which would be hard. So instead of letting the package cache grow boundlessly, it copies the required versions to every project.

If you have very many Unity projects using the same package versions, this could become a problem! The main issue is that the burst package is silly and contains 800 megs of libraries, if that was fixed most of this would stop being a problem.

The only way I can think of to work around this is to use symbolic links in some fun manner, but that would mean dealing with maintaining those by hand when you change package versions, which would be a drag.

1 Like

Yes, the Burst library is overly large, it would fix some of the issue if it was shared. There is even a copy of it in the main Unity package.

I don’t see other engines caching data like this though. Unreal projects don’t have large caches when working on them.

Flax Engine, which behaves a lot like Unity is extremely well optimized. I couldn’t believe how fast and small it was compared to Unity and it allows C++ to mix with C#. Projects are tens of MBs in size but the functionality looks the same.

Flax is mainly developed by one person so isn’t reliable for production but it’s extremely efficient. It would be good if Unity could get to that level of efficiency, bloated projects and codebases slow down the whole pipeline.

What most game devs would be better off with is a lightweight engine backed by a big company. Think Visual Studio Code vs Visual Studio. Some kind of Unity Vite engine that had the same scene format and APIs but minimal engine.

Fast compile times and hot reloading, minimal reliance on packages. Flax is so snappy, Unity and Unreal are always with the loading bars and huge projects, long publish times.

This could be good for schools teaching game development. People could bring the same projects into the larger Unity engine if they needed more functionality.

You are comparing Apples with Oranges. :wink:

To each their own. Don’t know Flax but Godot and it has big benefits, but also big letdowns. None of these engines support such a wide variety of platforms or providing so many features and feature options (for better or worse) like Unity does.

And with today’s hardware, I couldn’t care less if Burst in every project consumes one Gigabye of data. I’m not quickly running out of disk space with all my Unity projects as I am with just a single 10 minute video editing project.