Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Load time performance: Pack Separately twice as fast as Pack Together?

Discussion in 'Addressables' started by MikeHergaarden, Oct 13, 2019.

  1. MikeHergaarden

    MikeHergaarden

    Joined:
    Mar 9, 2008
    Posts:
    1,027
    For this game I have all 6 scenes assigned to the default addressables group, also all 50 cars and 30 customization prefabs. "Bootstrap" is the only scene in my build, everything else is in Addressables.

    The analyze tool made two extra asset groups: "Duplicate asset isolation" and "Duplicate asset isolation1" which contain many of the scenes shared assets.

    Load times in seconds
    PACK TOGETHER
    BootStrap.Start Preloader.Awake MainMenu.Awake
    Build 2.58 8.0 9.5

    PACK SEPARATELY
    BootStrap.Start Preloader.Awake MainMenu.Awake
    Build 2.5 4.18 5.8

    It seems that Pack separately (which creates 218 bundle files) loads much quicker then "Together" (5 bundle files)
    Is this expected behavior? And is it then indeed the best choice to always go for "pack separately"?
    This test was on PC, our target platforms are PC, Mobile & consoles.
    Note: Compression is disabled in all cases.
     
  2. Favo-Yang

    Favo-Yang

    Joined:
    Apr 4, 2011
    Posts:
    464
    It feels unintuitive, welI cannot think of a good reason of it.
     
  3. unity_bill

    unity_bill

    Joined:
    Apr 11, 2017
    Posts:
    1,053
    i'm surprised by the result, but could believe it could happen due to some complex dependency issues.

    did you run analyze, do loading tests, switch packing mode, delete duplicate groups, rerurn analyze, then rerun loading tests? I ask because you'll get very different dedupe layouts if you have pack together or separately on, and that could affect loading time.

    I would not say it's "always" best to go with one option or the other. Did you look at memory footprint? Your "pack separately" test should take up more memory than the together test. So at the very least, that may be a reason to choose to do things together.

    In general, only a couple giant bundles is going to be less optimal than many separate ones. Mainly for unloading efficiency. But usually less optimal for memory consumption at peak. So there are trade-offs. I'm surprised by this speed impact.
     
  4. JGrierson

    JGrierson

    Joined:
    Sep 12, 2016
    Posts:
    9
    This question is for Unity_Bill
    We have Addressables somewhat working but need a good use cases for reducing the load time of instantiating assets from asset bundles to the minimum time necessary. Right now to instantiate a single asset from a loaded asset bundle is taking 4-7 seconds. Not OK.
    Compression is turned off in all cases. These asset bundles reside on the Hard drive not on the Web. Our asset bundles consist of FBX's which contain meshes and textures. Eash FBX is roughly 20MB in size.
    Also we tried Application.backgroundLoadingPriority = ThreadPriority.High; to speed upo this process and this appears to do absolutely nothing! Is Unity really setting thread priority?
     
    Last edited: Nov 3, 2019
  5. unilsson

    unilsson

    Joined:
    Sep 17, 2019
    Posts:
    2
    @MikeHergaarden I'm not sure what you are measuring in your test. But if you have a large Addressable group (pack together, single AssetBundle). I've noticed that the first instantiation of an object in that bundle takes some time. No matter how small the asset is. Following instantiations from that group should be fast (unless you release the first instance and the ref count goes down to 0 again).

    In a test I did I had a group with 5 uncompressed textures (96MB) and 1 prefab (Unity cube, no material) resulting in an AssetBundle of ~500MB. When I instantiante the cube prefab for the first time on an Android device it takes around 4 seconds. Following instantiations are just fractions of a second.

    Doing the same test with pack separately is fast because the cube prefab is in it's own very small AssetBundle.

    I guess what I'm trying to say is that the first instantiation of an asset could be expensive (even for small assets) if you have large bundles :).

    Update:
    In my case it was the CRC check of the AssetBundle that caused the first expensive instantiation. If I uncheck 'Use Asset Bundle Crc' for the Addressables group the problem goes away.

    So if you need to have the CRC check enabled, notice that the first instantiation of an asset in a fairly large AssetBundle (300+ MB) could be expensive. At least on mobile devices.
     
    Last edited: Nov 8, 2019
  6. KB73

    KB73

    Joined:
    Feb 7, 2013
    Posts:
    234
    Any update re: investigations into addressables load time?
    We're still experiencing what we think is very slow loading relative to the old bundle system

    What is LoadAssetsAsync doing under the hood exactly? Is it opening and closing the bundle constantly ? Mulling just going back to the old system due to the performance but it is tricky to figure out what is causing this...any recommendations on identifying what the slow down is for our assets?

    We preload all our assets using LoadAssetsAsync and pass in the IResourceLocation list - all our addressables are under 1 group, LZ4, no caching, no CRC check etc and on an iPhone X - 80MB of assets till takes 7-10seconds to load, this seems very slow for whatever reason - our dependencies are very light. We simply just point to all the assets in the group and make 1 call to LoadAssetsAsync.
    Our previous titles using the old system loaded in sub-5 easily..

    thanks
     
    Last edited: Nov 26, 2019
    ImpossibleRobert and beecg like this.