The AsyncLoadingThread seems to be broken in the implementation of 4.13. Specifically; it’s having problems with blueprints deferring the loads of their object references. We’ve found significant load increases when using it, so we’d like to keep it on.
When I turn USE CIRCULAR_DEPENDENCY LOAD_DEFERRING off the issues stop happening; however - I’m having trouble understanding what the switch is intended to do or the consequences of turning it off. Am I correct in assuming it’s deferring all dependent object references referred to by Blueprints?
Hi Guillaume,
Could you provide us with more info on what specifically is broken? Is there a crash, and if so a callstack?
The circular load deferring is how we resolved a number of issues involving Blueprints and cyclic dependency chains. Without it, in certain scenarios, you could end up with crashes (especially in the editor - google “corrupted” Blueprints pre-4.7). As a simple explanation, what could happen is a Blueprint (A), which depends on a class or CDO from another Blueprint (B), could be loaded and used while B is half serialized somewhere up the stack. This caused a lot of problems back in the day, and we have made very concentrated efforts since to resolve this. More recently, this system has also been used to fix up problems where sub-class Blueprints were loading up with overridden values cleared (this too was a cyclic dependency problem).
Because our loader is recursive, what the load deferring does, is tries to put off loading all other Blueprint dependencies until the current one is finished serializing (ensuring a well formed object). In support of serialization, the load deferral system will stub in faux types for external Blueprint references, and then replace those post-serialization.
We’ve been running with the USE_CIRCULAR_DEPENDENCY_LOAD_DEFERRING define since 4.7, and it was more intended as an easy shut off in case it caused problems back in that timeframe. In general, it’s been working well since. In theory, if you are confident that your content creators are mindful of their dependency chains, then you could get away with turning it off (especially if it is working currently), but honestly it is not something I’d recommend.
I know there were a number of fixes to async loading in 4.14 (even more coming in 4.15), and I would recommend trying that first. Additionally, we’re working on a refactored, event-driven, loader for cooked/packaged projects. It attempts to get away from the recursive nature of our current system, and therefore doesn’t require the load deferral that we’ve had to do. I believe it went out as experimental in 4.14, but I know we’ve been ironing out the kinks since.
Hopefully this gives you enough insight to make the right decision.
Cheers! - MikeB