My load time per sprite went from instant to ten seconds when I switched from Resources.Load(key) to Addressables.LoadAssetAsync(key).WaitForCompletion().
Goal is to reduce update sizes by splitting up Resources into smaller files, so these are local bundles. I moved 150 enormous PNG files into a 1GB bundle with default settings (including LZ4 compression and CRC checks). During gameplay I occasionally load one random sprite from the bundle, display it, then Addressables.Release() it. During every load, the game froze for ten seconds while cpu and ssd disk usage moderately increased.
The culprit: CRC checks. Once I disabled them, sprite loading was back to the blink of an eye. So I have questions:
Is this a bug, or is 1GB just ridiculously large for an asset bundle?
Why are CRC checks enabled in the default local bundle template? Should they ever be used for local bundles?
What happens if a check fails? Will the game still crash but with a slightly more useful error message? If it’s a remote bundle, does failure trigger a re-download?
Does Unity also run a CRC check on the main Resources file, and can I disable that too?
Is there a way to pre-initialize a bundle and keep it ready to go? I noticed if I held on to one sprite, further fetches were instant. It was only after I released them all that the 10 second delay happened again. So I could hold onto one tiny dummy sprite to keep the bundle initialized. Feels like a dumb hack, but if there is any initialization overhead on this particular bundle, I only want to do it once at game start.
We also disabled CRC checks pretty much from right after starting to use Addressables and it didn’t seem to cause any issues so far. We don’t expect any files to get corrupted or tinkered with, but if that is a possibility in your case, CRC checks will probably catch maliciously crafted or just possibly crash-causing files. If the check fails, it will just not load the file I think (I’ve seen an error message once).
We don’t have such large files but the slowdown was still too much for us. Calculating a hash sum of a 1GB file just takes some time.
The 10 min on the CRC check deff seems like an issue, BUT having a 1 gig bundle is not something I would recommend.
I would try to split it up into multiple bundles that don’t go over 200 megs roughly.
There are various reasons such as; the load time of parsing the bundle for the asset you need.
Internet issues causing redownload of the bundle (getting 900 megs into a 1 gig download and having to restart it all is no good).
Needing to unload all assets from the bundle before releasing them from memory.
and a few others I think that aren’t coming to mind currently.
Also keep in mind, the full 1 gig needs to be downloaded before the asset can be loaded, and it was probably already downloaded on your second check.
I should have said obviously I’m not shipping with a 1gb file since the whole reason I’m doing this is to work around the 512mb update limit on Switch. The 1gb bundle was just my initial test, which failed so spectacularly I figured I’d find the cause before cutting it up. I was surprised because I was replacing a 4gb Resources file which had never been a problem, and Android OBB files can be up to 2gb.
My final bundles are all under 200mb. I used Pack Together By Label to split them up.
Edit: also note in my case the files are local (in the Streaming Assets folder), no downloading was involved.
It is different depending on the situation.
But a good rule of thumb is to enable CRC checking for internal bundles and cached bundles where you may have sensitive data. This type of content is also generally a ScriptableObject or small data files, so the CRC check is relatively small. You will also need to act on this if the CRC fails, such as telling the user that the installation is corrupted, or files have been tampered with, in which case you probably do not mind just closing. AFAIK most vendors/stores that users download the app binary will perform a check on the overall player, which includes the internal content, so it is often not necessary.
For downloads we recommend that the CRC is enabled. Where corruption of the file happens this is usually done during the download, and very unlikely to happen when writing to device or already on the device. The download CRC is also almost free, during the caching process we can calculate the CRC as it is being cached, without the high overhead of an already cached bundle.
Recommended default settings:
Internal/local Groups: Disabled
Remote Groups: Enabled (Excluding cached)
Then adjust depending on specific needs.