koobas.hobune.stream
Is there a way to optimize Loading.PersistentManager?
My team is hard at work creating an adventure game set in a large, 3 square-mile open environment.
Using Unity 5, we split around 40 big terrains into 10K smaller, more "streamable" chunks.
It works quite well, with terrain instatiation not taking too long, around 1 ms to be precise. The problem is that one Unity function is taking A LOT of CPU time, around 50 ms on my Intel i5. The function is called Loading.PersistentManager and I really don't know what it does.
I have read two threads on the matter, but no one seems to know anything about it and how to reduce its impact on the machine.
Any loading/streaming guru out there who could help?
Persistent$$anonymous$$anager is an internal class that manages loaded objects. Loading.LockPersistent$$anonymous$$anager time corresponds to the read object's data event. How do you load the terrain chunks - are you using LoadLevelAdditiveAsync/LoadAssetAsync? And what are the chunks - scenes/prefabs?
We use Resources.LoadAsync to load prefabs that contain several GameObjects (branches, decals, trees) and one terrain for each call. It is weird as this overhead only appears in a build, not in the editor.
$$anonymous$$ore likely it is waiting for completion of some other load operation. $$anonymous$$ight also happen if you access ResourceRequest.asset before loading is done (http://docs.unity3d.com/ScriptReference/ResourceRequest-asset.html).
To quote my colleague post on the forums: "...it seems to be only in a built player. We load small terrain chunks asynchronously and it works quite well, but every now and then Loading.LockPersistent$$anonymous$$anager shows up and takes a lot of time. It happens when we access the ResourceRequest.asset value. When I decompile UnityEngine.dll, it shows that ResourceRequest.asset calls Resources.Load(string path, Type systemTypeInstance);
I guess it has to do with some kind of multithreaded lock. Resource.Load must try to access some locked value while another background loading is taking place in another thread, making the main thread wait for this loading to end. It seems to happen less frequently in FixedUpdate(), but it may be an illusion.
No matter where I put the ResourceRequest.asset call, it still happens. It would be pretty nice if Unity would fix this. I might try to make a small project to submit a bug, but it's a bit tricky."
For what it's worth, LoadAsync("") tells Unity to load EVERYTHING in the Resources folder. That is a pretty expensive operation.
Thank you... that one nugget of information is priceless!
I just had this problem too, and it was because we were doing Resources.LoadAsync() on an empty or null string (it might also happen if the resource doesn't exist). I was seeing the same thing with Loading.LockPersistentManager, but in my case it was taking 3000+ ms!
I fixed the bad Resources.LoadAsync() call and now it's working normally again.
