Copy on Write AssetPaths

[cart]

Objective

The AssetServer and AssetProcessor do a lot of AssetPath cloning (across many threads). To store the path on the handle, to store paths in dependency lists, to pass an owned path to the offloaded thread, to pass a path to the LoadContext, etc , etc. Cloning multiple string allocations multiple times like this will add up. It is worth optimizing this.

Referenced in #9714

Solution

Added a new CowArc<T> type to bevy_util, which behaves a lot like Cow<T>, but the Owned variant is an Arc<T>. Use this in place of Cow<str> and Cow<Path> on AssetPath.

---

Changelog

• AssetPath now internally uses CowArc, making clone operations much cheaper
• AssetPath now serializes as AssetPath("some_path.extension#Label") instead of as AssetPath { path: "some_path.extension", label: Some("Label) }

Migration Guide

// Old
AssetPath::new("logo.png", None);

// New
AssetPath::new("logo.png");

// Old
AssetPath::new("scene.gltf", Some("Mesh0");

// New
AssetPath::new("scene.gltf").with_label("Mesh0");

AssetPath now serializes as AssetPath("some_path.extension#Label") instead of as AssetPath { path: "some_path.extension", label: Some("Label) }

[alice-i-cecile]

Reasonable enough, but it is a shame we don't have benchmarks or even stress tests for asset processing currently.

[cart]

We have a pseudo stress test in the form of running the asset processor on everything in the assets folder. This is as simple as turning on AssetPlugin::processed_dev() in any example and running it. It will log the total duration. To repeat, just delete the imported_assets folder and run again.

I ran that about 10 times for both main and this pr before submitting it and the change here was dwarfed by very swingey results (my guess is filesystem i/o). We might need something a bit more targeted to isolate the perf difference.

[cart]

However given that Arc<str> is essentially a referenced counted String, imo this really does come down to the cost of reallocating a string on clone vs incrementing an atomic index (which should definitely be a win in this case).

[alice-i-cecile]

Yep, agreed with your instincts here. Thanks for testing that; I'll spin out an issue.

[tguichaoua]

CowArc is missing Display and also Ord and PartialOrd to be complet. But since the last two are not used in bevy I think it's ok to omit them.

[killercup]

Makes sense but would be good to see benchmarks, maybe also to see how much memory pressure is related to this.

I think there's a couple crates out there that try to make atomic string types as small as possible (at the cost of indirection). If this turns out to be performance critical, maybe some of their tricks can be implemented generically here, too.

[cart]

Something else interesting we could consider: add a CowArc::Static(&'static str) variant and change From<&'a str> to From<&'static>.

This would do two things:

1. It would remove the need to produce owned / Arc-ed strings for static strings. Clones of these types become "just" a &'static str pointer copy, and we retain this context transparently as things like AssetPath::into_owned are called.
2. It would force non-static &str to go through a different constructor (ex: manually call the AssetPath constructor for asset_server.load(AssetPath::new(some_non_static_str)). HOWWWEVER, we would still have From<&'a String>, which means asset_server.load(&some_string) would still work. This would only apply to explicit &str types, which are even less common.

The theory being that a very high percentage of paths defined in user code are static strs. AssetLoaders basically never use static strs, but every case in the built in Bevy AssetLoader code uses &String, so no changes were necessary.

But it would come at the cost of nasty ergonomics / confusing apis for borrowed strs.

It would also make CowArc much more opinionated. But this would likely save a lot of work on average and so far the UX hit seems pretty much non-existent.

I had to change zero Bevy examples or AssetLoader impls after the change.

[cart]

I just pushed the change to illustrate. We can revert if y'all don't like it.