I am wondering which option is more efficient (and why): WWW vs. DownloadHandlerAssetBundle
According to the DownloadHandlerAssetBundle docs here -
In a naive implementation, we are downloading content at runtime via WWW, then manually cache it to disk (by reading the www.bytes property. This allocates a lot of memory (since we read the whole bytes array and write it to disk, which allocates a lot of memory).
On the other hand, using tools such as the Unity profiler, or external (3rd party) profilers did not show me any meaningful insights whether one option is better than the other in terms of memory usage.
So, what are the benefits of switching to DownloadHandlerAssetBundle, and how can i really measure to see its effectiveness ?
WWW.LoadFromCacheOrDownload will use DownloadHandlerAssetBundle under the hood, so efficiency will be the same aside from WWW object created on top.
If no caching is used, both will store everything in memory.
If you do a manual caching, then you should probably use DownloadHandlerFile, this will write bytes to disk on the fly.
We are not using LoadFromCacheOrDownload, we have something like this:
var www = new WWW("url");
// TODO: Download using www
var data = www.bytes;
File.WriteAllBytes(data, path);
I’d like to replace all of this with DownloadHandlerAssetBundle that uses Unity’s built-in cache.
From what i saw using the profiler and other tools, there were no obvious improvements, and i am wondering why.
DownloadHandlerAssetBundle does the same thing as LoadFromCacheOrDownload. The benefits depend on asset bundle size and compression used, as well as internet speed. With your current approach the entire bundle is stored in memory and all processing of it happens when you load it. With DownloadHandlerAssetBundle the recompression and storing into cache happens as the data comes. For large bundles it saves some memory and decompression spikes can be avoided by decompressing on the fly rather than all at once later.
From what you are saying it seems like this will not result in dramatic memory improvements. Our asset bundles are 10mb MAX, not larger than that. I was under the assumption that the DownloadHandlerAssetBundle will be much more efficient as it will not allocate any managed memory (e.g: like we are doing now when reading www.bytes data to save the data to disk).
Is there any better approach (in terms of memory usage and re-compression) other than what i am currently checking ?
That is the case. The downloaded bytes are stored in native memory and then the managed allocation happens when you access .bytes. With DownloadHandlerAssetBundle you save some native memory and avoid managed allocation completely.
Yet, I don’t understand why you don’t use LoadFromCacheOrDownload in your current code using WWW?
Our code exists for a long time, LoadFromCacheOrDownload didnt give us flexibility in the past for controlling certain aspects of the caching, so we wrote our own cache system.
Is there any better and more optimized solution than what i am trying right now then? e.g: DownloadHandlerFile or something else?
DownloadHandlerAssetBundle does have some more options compared to LoadFromCacheOrDownload.
But if that is not enough, then DownloadHandlerFile is the most efficient way to download and save file to disk.