Burst drastically increases project size. Is this the new normal?

I looked back at my projects from the 2017 and 2018 editors and the size of small project folders rarely exceed 100MB in disk space even when including the Library folder.

But now all new empty projects that require burst (such as URP) take up at least 1.4GB disk space right upon project creation.

Is this just something I have to get used to? It seems like such a large amount of disk space for an empty project when just a few years ago new projects were as little as 25MB. That's a 60x size increase.

 

Go dig around in the Library/PackageCache and see how big each module is.

 

Yeah I know that packages are the main culprit for the increase in project size, but given that a lot of these packages are built-in or required, (like burst which is the largest contributor at ~1GB of disk space per project), they basically need to exist. So do I just have to accept that whatever additions Unity added to projects, the default project size is now ~1.5GB instead of <100MB like a few years ago? Or am I still misunderstanding something.

Does each project require its own Burst package? Or is there a way for all projects to share one Burst package linked to the editor?

 

In theory a symlink (known as a directory junction under Windows) should allow you to store a single version in one location and reference it in every project. Unfortunately I tried to do so with Unity 2022.1 and noticed it overriding it every time I loaded the editor creating a new copy in the cache folder.

What did work was enabling compression on the folder shrinking it from 834MB to 534MB, and I was able to enable compression on the entire project shrinking it from 1.26GB to 765MB. I don't know if I would necessarily go that far though as compression does impact read and write performance.

Burst is as large as it is due to all the components needed to make it function. These components consist of the LLVM compiler and linker. For standalone it has the Windows, Mac, and Linux binaries adding up to 380MB. The library binaries make up most of the remaining 460MB.

 

@Ryiah - were you creating a symlink of each individual package, or of the PackageCache folder itself?

I wonder because I can see Unity deleting and recreating the per package folder which would break the symlink. But I would bet Unity would not touch the PackageCache folder itself as long as it existed.

Of course I may be wrong in my guess... if only because I never really tried setting something like this up.

Main reason being, the size of the package cache's don't really bother me all that much. Storage drives these days tend to be so big that a gig here or there isn't really a problem to me.

At any given time I have like 10-15 projects on my local machine. Even at the sizes OP is saying we're talking what... 15-20 gigs?

Actually... my projects are significantly bigger than OPs since without the packages they're still gigs in size (textures, models, audio, git repo history folder, etc). And my 15 or so projects currently on my machine are 60 gigs. But I don't really feel that all that much.

Of course this could potentially be an issue if I stored ALL my projects locally. But that's what I have git for which I push to my remote all the time. I only keep the projects I need currently on my machine (and "need" is used loosely here since I technically don't need all 15 of these current projects on my machine).

Of course, it'd be annoying if this packagecache was in the repo... but that's why I add that folder to the ignore file.

 

Just the individual package.

Edit: Okay. I just tried the PackageCache and it's not replacing it. In fact I have two different projects open at the same time both referencing the folder. Adding a package to one added it to the folder but not the second project which makes sense as the package manifest wasn't being changed for the second.

After confirming that it had added it to the cache I told the second project to add it and it showed up in that one too. What didn't work as you would expect is removing a package with the other opened. That caused a lockup for the one not told to remove it. Once it was forcibly closed and reopened though it added the package back.