Before Boot -> PIE
FPackageName::DoesPackageExistEx called 191284 times takes 16.45s in total
After Boot -> PIE
FPackageName::DoesPackageExistEx called 191743 times takes 1.61s in total
The majority of the 1.6s (1s) is from calling DoesPackageExistEx before the AssetRegistry has initialized and can provide a fast path. The 180K calls afterwards consume a total of 600ms compared to before, which took 15s.
The original DoesPackageExistEx code checked for package existence on the filesystem, and at the same time found the case matching package name (the casing the file system uses for the package name). This information is known to the AssetRegistry so we can avoid the duplicate work by deferring to the AssetRegistry.
The AssetRegistry needs to initialize itself, and previously did not expose a means to get the Case Matching FNames for Packages which are being used as the keys to AssetPackageData. We add a new overload to IAssetRegistryInterface::TryGetAssetPackageData to allow CoreUObject code to access the another new overload in the AssetRegistry::GetAssetPackageData which returns the case matching FName for the package as an out parameter. Since IAssetRegistryInterface can be used while the AssetRegistry doesn't exist or is still intializing, IAssetRegistryInterface::TryGetAssetPackageData will return UE::AssetRegistry::EExists::Unknown when the asset registry is not yet available. In the Unknown case, we fallback to the original FPackageName::DoesPackageExistEx codepath which reads from disk.
I've made the (Try)GetAssetPackageData methods that only return FAssetPackageData* to use the new implementation that returns a FAssetPackageData* and populates an FName in order to reduce code duplication, however I'm open to changing this if the extra store is a concern. All paths perform the key search in the AssetRegistry's CachedAssetPackageData map.
#jira UE-204062
#rb Matt.Peters
[CL 31055136 by kevin macaulayvacher in ue5-main branch]
simplifies usage of Object Properties and fixes a few edge cases
see zousar.shaker for issues
#rb zousar.shaker
[CL 29761675 by joe pribele in ue5-main branch]
Further improvements to be had by avoiding CheckCallable overhead of TFunction and making a lockless container to store read callbacks. Those will be investigated in future changelists.
#rb joe.pribele
[FYI] dan.oconnor
[FYI] ben.zeigler
[CL 27728373 by zousar shaker in ue5-main branch]
1) Fix for test package names not starting with proper prefix
2) Fix incompatible value that is passed into CheckValidObject to NOT be the outer of the fallback objecte. The incompatible value now gets renamed by CheckValidObject, and renaming the outer of the fallback object would break the test.
#rnx
#rb Joe.Pribele
[CL 26474125 by Matt Peters in ue5-main branch]
Disabled by default. gc.AllowIncrementalReachability controls if it's enabled or not.
gc.IncrementalReachabilityTimeLimit controls time limit (defaults to 0.005 = 5ms)
gc.VerifyNoUnrachableObjects (defaults to 0) controls additional GC assumption verification that no unreachable objects are reachable after RA is complete
gc.ContinuousIncrementalGC (defaults to 0) is a new GC stress test that runs incremental GC continuously
TObjectPtr barrier (Obj->MarkAsReachable()) is also currently disabled (compiled out with a macro) until we have all the places (ARO/BPVM) properly running barriers
EngineTest tests can and will run Incremental Reachability Analysis tests even if all the above is disabled
#rb Johan.Torp, Zousar.Shaker
[CL 26252569 by robert manuszewski in ue5-main branch]
Disabled by default. gc.AllowIncrementalReachability controls if it's enabled or not.
gc.IncrementalReachabilityTimeLimit controls time limit (defaults to 0.005 = 5ms)
gc.VerifyUnrachableObjects (defaults to 0) controls additional GC assumption verification that no unreachable objects are reachable after RA is complete
gc.ContinuousIncrementalGC (defaults to 0) is a new GC stress test that runs incremental GC continuously
TObjectPtr barrier (Obj->MarkAsReachable()) is also currently disabled (compiled out with a macro) until we have all the places (ARO/BPVM) properly running barriers
EngineTest tests can and will run Incremental Reachability Analysis tests even if all the above is disabled
#rb Johan.Torp, Zousar.Shaker
[CL 26229728 by robert manuszewski in ue5-main branch]
moved leak detection and Garbage collection to Plugin Manager
Before unmounting the plugin path, GC is ran, leaked detection for any references objects under the plugin path
#rb Justin.Marcus, Markus.Breyer
https://p4-swarm.epicgames.net/reviews/25611054
[CL 26214355 by joe pribele in ue5-main branch]
Before unmounting the plugin path, GC is ran, leaked detection for any references objects under the plugin path
#rb Justin.Marcus, Markus.Breyer
https://p4-swarm.epicgames.net/reviews/25611054
[CL 25858446 by joe pribele in ue5-main branch]
changed how the Object Handle index stores info to be able to get the class of the outer objects
Packages dont' store a ObjectPathId or ClassDescriptor as it is always known
https://p4-swarm.epicgames.net/reviews/25378953
#rb zousar.shaker
#preflight 64791957e25209b6cbbb45fc
[CL 25747367 by joe pribele in ue5-main branch]
this matches the uht generated code more closesly
https://p4-swarm.epicgames.net/reviews/25707323
#rb matt.peters
#preflight 64791483e25209b6cbb931ac
[CL 25746642 by joe pribele in ue5-main branch]
