Continual degrading performance on loading lots.

I have noticed that performance has continued to degrade on loading lots. This leads to a lot of hitching and stuttering.

A few things can be done about this. (If they haven't already) Please note that this is all limited to Unity specific options. I am intentionally leaving out a lot of options not available on Unity, because I don't want to go into a Unity sucks rant.

1. To improve texture loading without reducing quality, switching to BPTC (i.e. BC7) would improve quality AND reduce loading time, at a small penalty for added GPU core processing usage (which isn't a current bottleneck) .
See: https://docs.unity3d.com/Manual/class-TextureImporterOverride.html

2. Insure that the right compression format is for the right type of bundle.
a. Bundles loaded all at once should be using LZMA compression, as it achieves the highest compression ratio at little cost.
b. Bundles requiring random access should be using LZ4 as it doesn't require the entire bundle to be decompressed to access one piece of it.

By this standard Scene primary bundles should use LZMA and lot decoration bundles should use LZ4.

3. Insure files are opened in the right manner.
a. Loading asset files in memory is fast, and inflates the heap all at once. It also handles LZMA compression a lot faster. This should be used for when doing initial scene loading. Once loaded the file handle should be closed, and GC should be run.
b. Loading assets from disk has low memory impact, and does not require reading the whole file. This works good for LZ4 compression, and random access assets. This should be done for loading lot decorations.
See:
https://docs.unity3d.com/Manual/AssetBundles-Native.html
https://docs.unity3d.com/ScriptReference/AssetBundle.html

As of whether you should use use asynchronous or synchronous. They both have advantages. However, avoid synchronous access on any thread that will create world locks during file access (especially on world thread.) I'd simply profile each option on a variety of systems and find what works best for each task.

Note, that you can also load from stream using an external file handler helper. However, I haven't looked much into this option. It might give some gains, but is probably not worth the effort unless you can find a suitable solution already made.

 

As a note, I noticed a LOT of VERY large open virtual file buffers. This may be detrimental to game performance, even if those buffers aren't resident in memory they are using a lot of pointer space and such.

 

BTW, if you want to hear a summary of my Unity sucks rant on this topic.
Something Something . . . no sparse asset loading.
Something Something . . . no block-based LZMA
Something Something . . . no LZO compression at all
Something Something . . . no object tree barriered compression.
Something Something . . . Null returns make asset loaded status checking more difficult.
Something Something . . . Horrible archaic GC makes this all worse.

Hope that cynicism makes you smile a little.