What exactly does "Async Load Class Asset" on a Soft Class Reference pointing to a native C++ class ?

[GabUECV]

In a Blueprint, it looks like that the memory implication of having a Hard Class Reference variable pointing to a native C++ class is zero (contrary to pointing to a Blueprint Class for example, as in this case, it shows up as a dependency in the Asset References Viewer).
Please correct me if I’m wrong.

But I am wondering about Soft Class References pointing to native C++ classes. As there is the need to “load” them, is there any performance or memory implication by doing so ? What does it mean to “load” a C++ class ?

I can see what it means to load a Blueprint class for example (Blueprints are assets that needs to be loaded in memory), but I can’t see what exactly does Unreal Engine under the hood for native C++ classes, as all of them are already in the binary code of the project.

Does it simply does nothing and just return the UClass ? Or maybe there is some specific cases with classes in plugins or .dlls not actually loaded automatically ?

Also, where can I find the actual implementation of this Soft Classes References loading in the Unreal Engine code, so that I can review what is being done exactly ? I am having troubles to find exactly where it is done, the code base is quite huge

[GabUECV]

For those interested, I finally got my hands deep into the Unreal C++ code and found this:

Loading a native C++ class from a soft object reference is basically a no-op (except for boilerplate code to actually create the async task, resolve the object in memory from its class name, etc.). These are always pre-loaded in memory, as I suspected, and contrary to blueprint classes which are assets that needs to be streamed.

Technically, it is done here in the source code (starting from the Async Load Class Asset node code) :

UKismetSystemLibrary::LoadAssetClass >              
  FLoadAssetActionBase::FLoadAssetActionBase > 
   FStreamableManager::RequestAsyncLoad >
     FStreamableManager::StartHandleRequests >
       FStreamableManager::StreamInternal >
         FStreamableManager::FindInMemory >
           StaticLoadObject

Activating verbose logging for StreamableManager leads to console log output like this, which also confirm the observed behavior :

The BP code that trigger this output is simply 3 consecutive Async Load Class Asset on 1 native C++ class, and 2 BP classes. Indeed, the first one is already in memory, while the others two requires streaming from disk.

“Loading” a C++ class simply involves a hash table check from the class name to the UClass object loaded in memory (this is what is doing the StaticLoadObject function)