Do asset IO on bg thread #29016
Do asset IO on bg thread #29016
Conversation
|
#22077 just came up in the triage, which looks related. |
|
Talked about this offline a bit. We don't have any clear evidence that this will help things. This only affects a relatively narrow set of cases: image loading, SVG loading, or otherwise loading data packaged as an asset. This data is typically small, so loading it is typically fast, and the thread hop would likely if anything regress performance. We could definitely construct an example where this makes a difference (e.g. loading some large asset file), but it's unusual for applications to include large assets. We should add some tracing around calls to this and try to better understand how much it actually costs/when it's a problem. |
|
This now has a test, but still needs a little bit of checking to see if it actually improves or regresses benchmarks. Conceptually it seems like the right thing to do. It should probably help when larger assets, such as flare/rive animations are used. |
|
Looking at startup traces, I think this would probably hurt, particularly on low end phones. We rely on being able to read some manifest files very quickly this way - traces even on a low end phone are on the order of us/ns. If we have to do thread hops for that it will almost certainly be slower on 4 core devices. However, it would probably still be a good idea to do this after we've started rendering frams. |
|
In looking at traces, I can find lots of examples where the current behavior actually helps us and I have not really found any clear ones where it's hurting us. Going to close this for now, not really clear how to make it help. |
2 participants
@goderbauer