Why high-priority assets don’t load first in RequestAsyncLoad?

What does the Priority parameter in FStreamableManager::RequestAsyncLoad do? When I make the call, I set different values for various resources—some have a high priority like 100, while others use the default 0—but the high-priority resources I specified don’t seem to finish loading first. How does this Priority parameter work at the underlying level? Which relevant code do I need to examine?

[Attachment Removed]

重现步骤
const FSoftObjectPath AssetPath1 =…;

const FSoftObjectPath AssetPath2 = …;

FStreamableDelegate DelegateToCall1 =…;

FStreamableDelegate DelegateToCall2 =…;

GetStreamableManager().RequestAsyncLoad(AssetPath1, DelegateToCall1, 0);

GetStreamableManager().RequestAsyncLoad(AssetPath2, DelegateToCall2, 1);​

[Attachment Removed]

Hi there,

I’ve had a look into this and done some testing. You might be seeing this occur due to the async nature of the function. When testing random assets with random priorities the completion time for these would mostly depend on the size of the asset.

When testing multiple assets that have the same file size (e.g. duplicate assets). The priority was respected according to the documentation, 0 being default & higher numbers having a higher priority). Even when making the requests in a random order or stalling them before processing a later time. However if the assets are already loaded then they wont be processed & will finish in the order that the requests were made. This includes when testing between multiple PIE sessions.

Does this line up with the behavior you see? If not could you give me some addition details about how you are calling? e.g the type & size of the assets. What time of runtime scenario PIE, Editor, Packaged build etc.

Cheers,

Louis

[Attachment Removed]

Thank you for your prompt reply.

I’m not sure if my understanding is correct. It seems that the priority only affects when the asynchronous load starts, especially when multiple async load requests exist simultaneously. It does not appear to provide a per-frame persistent I/O priority.

In other words, even if Asset A has a higher priority than Asset B, A will only start loading before B—but this priority does not guarantee that B’s loading will only begin after A has fully finished. If that is the case, A’s total load time could be significantly prolonged by B, since the per-frame I/O opportunities are effectively fair between them.

Is my understanding correct?

[Attachment Removed]

Although I haven’t studied Lyra’s AsyncMixin, I guess it implements a serial asynchronous loading mechanism at the upper layer. In this way, it will not block the main thread and can also achieve similar priority control.

Okay, thank you for the important information.

[Attachment Removed]

Hi again,

Yes that lines up with my understanding as well. If this is an issue and you want an asynchronous load with queuing I believe the AsyncMixin class in the Lyra Starter Game sample project has this functionality.

- Louis

[Attachment Removed]