I’m investigating ways to improve load times when opening our world map in Editor, to improve workflows for our developers.
We are using World Partition, OFPA. The map size is approx. 20km x 15km.
We currently have about 300k actors in the world and this will keep growing. About 9k actors are always loaded.
Load times are typically 3 minutes for first load, less for 2nd load, and about 1m 30s for subsequent loads. I’ve attached a screenshot from a typical Insights capture.
What tips and best practices can you give for keeping map load times at a minimum when working in large worlds? Is there anything that jumps out here as indicating less than best practice?
The LoadAlwaysLoaded is for “non-spatially loaded assets”. This should not be 75% of the load time. Which hash are you using? If using the SpatialHash, you can try setting the following cvar to reduce the amount of Actors being promoted.
There are a couple of things that can affect the loading speed from the point of view of the workstation hardware and config.
HDD vs SSD: OFPA comes with tons of files so faster SSDs (Raid?) are almost essential to promote shorter load times.
Last Access Time: This is a default of NTFS so that the file records are updated every time the files are read. You can turn it off to get a speed boost.
from a command prompt with Admin privilege: fsutil behavior set disableLastAccess 1
You must reboot the system for the setting to take effect
Anti-virus\malware: Those are known to slow down file access. We recommend setting an exception on the Editor process OR the folder that host the project
The Windows cache: The file system caches any file read IF there is enough RAM in the system. You can use tools like RAMMAP to monitor the files that are currently cached. This can have a direct impact on subsequent loads.
The following post is also interesting here: [Content removed]
The TLDR is that a customer found that calls to FFileHandleWindows::ShrinkBuffers are slowing things down because the handles are reopened. The goal of the reopen operation is to save on RAM usage which can improve the cooking time (less GC required) .
I’ve managed to reduce the number of always loaded actors to 2K, and that’s knocked 40 seconds off the load time. I expect to be able to reduce this by another 1K actors soon.
Just want to feed back something I’ve noticed, which is that the way the user opens the level has a significant effect on load time:
Opening by double-clicking the asset in the Content Draw = slow
Opening via the menu (File > Recent Levels > …) = faster by about 40 seconds!
The trace capture at the top of the thread shows when loading via the Content Draw. The one below shows when loading via the menu. It shows that UWorldPartition::Initialize() is called just once here, hence the time saving.
So these 2 things together have almost halved our load times. I’ll look at your other suggestions too.
That is an interesting finding. I have been able to reproduce the problem internally. It seems to be linked to the way the Content Browser is loading packages. The main difference appears that the content browser preloads the package before loading is as a Map. I tried to skip the first WorldPartition initialization but it didn’t help as other systems ended up taking the extra time.
I have logged an internal work item so this can get reviewed by the editor team.
I’m not sure what the Inactive world is being used for but there seems to be some need to have some parts minimally initialized. I did try to prevent the WorldPartition from initializing when called through that code path. That feels safer as the WP is uninitialized soon after that anyway. It didn’t really help as I ended up waiting on the async load of some assets (mainly Skel meshes)
This is what I’m getting starting with the Menu and Content Browser:
[Image Removed]
This is when I skip the WP initialization:
[Image Removed]
I’m only getting a 2 seconds improvement which is not great. This will need the Editor team to review the behavior and ■■■■■ how this can be changed.
Don’t be fooled by the Asset Compiling Manager in there. This does “compile” the assets but also loads them from the cache asynchronously. All my tests are using City Sample with a warm DDC so it’s only loading.
This would probably be a YMMV case as it depends on the assets being referenced by the WP level.
BroadcastPreGarbageCollect in my case is related to flushing the async loading pipeline. This depends on the content referenced by the loaded level. Skipping the WP initialization can help if there aren’t many assets being loaded asynchronously based on what you report.
I have created an internal ticket for the Editor team to review the situation. It’s unclear to me why opening an asset through the content browser pre-load the package. It might just be a case of adding an exception in the case of a WP level.
I found that in UEditorEngine::OnAssetLoaded, if you skip calling InitializeNewlyCreatedInactiveWorld, you get the benefit of the quicker load time. But not sure of the implications of doing that?
Yeah, when I try the same I get a much bigger improvement than what you’re seeing. I don’t get a large BroadcastPreGarbageCollect like you do. It saves about 40 seconds for me.