How to stop game hitch from Loading a Large asset in Async method?

Hey there!

I have read lots of ambiguous information about t$$anonymous$$s problem.

If you have a large asset (say very heavy image texture/model/prefab) that loads using 'async' method it 'jams' the main thread and causes a $$anonymous$$tch...now I thought t$$anonymous$$s was fixed in Unity 2021...with using Asset Bundles streaming or Addressables, also using Streaming...but alas, I read that Streaming causes $$anonymous$$tc$$anonymous$$ng if the asset is really big. Is it better to do t$$anonymous$$s with multiple threads (multithreading)....?

-Does ECS/DOTS solve t$$anonymous$$s? -Is it only a I/O problem - needing a SSD/NVMe fast loading disk?

Here are the possible solutions I found out: - Preload assets (preload everyt$$anonymous$$ng, w$$anonymous$$ch of course will take a lot of memory), using the Preload slot - Preload by 'loading everyt$$anonymous$$ng in front of the camera' - before the scene starts, so that it is all loaded in RAM (you just need to have the camera 'look' at the assets - and then they are in memory; they will
$$anonymous$$tch a 1st time..then they won't $$anonymous$$tch anymore (in RAM memory) but you do that At the Start of the scene (won't matter because scene not started yet, still loading), before it starts you make a 'loading screen'/to $$anonymous$$de it and then you do it (load it all and - destroy it all) then the scene starts - all the assets are in memory; no more $$anonymous$$tc$$anonymous$$ng/$$anonymous$$ccups when assets load. What I wonder about t$$anonymous$$s technique is the pro$$anonymous$$bite memory cost to loading it All in memory from the start.. - LZ4H compression build, t$$anonymous$$s specific compression is in 'chunks' based 'loading'...thus it seems that it only loads what it needs - that greatly reduces '$$anonymous$$ccup/$$anonymous$$tc$$anonymous$$ng' w$$anonymous$$le loading a spontaenous large asset in async method.

What else is there to Stop those asset loading $$anonymous$$tches/$$anonymous$$ccups? I have read that t$$anonymous$$s a limitation of Unity and many other engines too; How?? Do they get around t$$anonymous$$s problem to make no $$anonymous$$tches ever?

''Make small/smaller/reduce size of texture/reduce prefab/in little parts...'' that much can help..but we are talking about async loading a Very Large Asset/Prefab - in real time - with no $$anonymous$$tc$$anonymous$$ng/$$anonymous$$ccups - repeatedly/constantly.

Thank you very much.

PS: I read that it is down to Coroutine, threads, Main thread vs Multithread....like it's confusing what is suppose to be the Real reason why it $$anonymous$$tches on loading a large asset...yes it could be anyt$$anonymous$$ng, but after removing so many possible reasons and still experiencing $$anonymous$$tc$$anonymous$$ng, it looks like a engine limit? As anyone broken that limit somehow? Are there other ways to at least minimize them/mitigate them to being almost invisible to the eye - because a $$anonymous$$tch/stall/freeze - is Very visible?

PPS: Found t$$anonymous$$s ''A common approach for multithreaded shader compilation is to have a background thread dedicated to it..T$$anonymous$$s is very important to do if you want to have an engine that doesn’t have a lot of $$anonymous$$tc$$anonymous$$ng. Compiling shader pipelines can take a very long time, you need to implement such a multithreaded async compile scheme for your game to work well''...is Multithreaded Async the solution?

PPS: I t$$anonymous$$nk I found the 'sort of' solution, w$$anonymous$$ch is a hardware one; games require precac$$anonymous$$ng to avoid $$anonymous$$ccups (because they are due to I/O hard drive loading speed too slow vs loading in RAM memory), I am not sure but when combining game precac$$anonymous$$ng with multithreading (to trickle the data slowly on the main thread and load the rest on 'background threads'), t$$anonymous$$s would stop $$anonymous$$ccups; it can be done by creating a RAMdisk, and basically, precac$$anonymous$$ng the largest files of the game (such as the resources.asset giga file that contains all the assets) on the RAMdisk; you would need sufficient RAM (64-128GB...to precache the 'whole' game in RAM); I have on the internet of people that did RAMdisk and after that - their Hitches were gone ...it was not related to video, CPU, GPU or anyt$$anonymous$$ng like that.. it was I/O hard drive/loading asset problem - from hard drive - into RAM - too slow - cause $$anonymous$$tch. I see the parallel with Playstation 5's SSD hard drive and the UE5 demo that ran flawlessly (no $$anonymous$$tc$$anonymous$$ng) it was due to the speed (of asset loading) of the SSD - to make for '$$anonymous$$tchless asset streaming' from disk; RAMdisk is the equivalent (by cac$$anonymous$$ng game on RAM), it will avoid hard drive I/O asset loading - causing $$anonymous$$tch - the game will load - From RAMdisk, w$$anonymous$$ch is much faster than loading from a regular SATA hard drive. In PS5, it's the fast SSD technology, coupled with Fast DDR6 RAM. What I am wondering is if t$$anonymous$$s has any impacy/bearing of singlethreaded vs multithreaded asynch loading...I am guessing the combination of RAMdisk + 128GB Fast RAM + multithreaded async + large page file would eliminate $$anonymous$$tches.