Remove usage of String in the asset manager

[bjadamson]

Looking up resources by a string is convenient but slow thanks to dynamic allocation. I believe this is why OpenGL uses integer handles, even if it they are less convenient to work with.

These string should be replaced with type-safe integer wrappers, or some other design to improve the performance of the asset manager.
https://github.com/amethyst/amethyst/blob/develop/src/context/src/asset_manager.rs#L41-L42

Consideration must be given to the current convenience though, especially if it is removed.

Maybe offering both versions make sense? What does everyone think?

[OvermindDL1]

Shouldn't most asset strings have the 'key' only allocated once per app? If not then a flyweight string container could do that. That way you get a unique id comparison via taking the pointer of the string or the appropriate method in rust.

[OvermindDL1]

Shouldn't most asset strings have the 'key' only allocated once per app? If not then a flyweight string container could do that. That way you get a unique id comparison via taking the pointer of the string or the appropriate method in rust.

[bjadamson]

Shouldn't most asset strings have the 'key' only allocated once per app?

I agree this is probably true, but it's forcing the user to use a string when they otherwise would not. That's really what I'm trying to point out.

If not then a flyweight string container could do that. That way you get a unique id comparison via taking the pointer of the string or the appropriate method in rust.

This makes sense in the current implementation to me.

[bjadamson]

Shouldn't most asset strings have the 'key' only allocated once per app?

I agree this is probably true, but it's forcing the user to use a string when they otherwise would not. That's really what I'm trying to point out.

If not then a flyweight string container could do that. That way you get a unique id comparison via taking the pointer of the string or the appropriate method in rust.

This makes sense in the current implementation to me.

[bjadamson]

Here's a pull request showing what I'm thinking.

#90

Any thoughts? I'd like to audit everything for this change. I'm happy to add some implementation of string based asset-management that's built ontop of this, if that's desired. My real goal is to allow myself a path for not using strings here.

[bjadamson]

Here's a pull request showing what I'm thinking.

#90

Any thoughts? I'd like to audit everything for this change. I'm happy to add some implementation of string based asset-management that's built ontop of this, if that's desired. My real goal is to allow myself a path for not using strings here.

[Geemili]

Could we make it a generic so that the user can decide?

Another thought I had is making a build script that takes a resource file and bakes the strings into integers, similar to how android does it. The build script could generate a bunch of environment variables like AMETHYST_RESOURCE_ID_sphere_mesh=123. After the environment is generated, the user can just include using:

let sphere_resource = env!("AMETHYST_RESOURCE_ID_sphere_mesh");

Or even a custom macro so we can omit the prefix:

let sphere_resource = resource!("sphere_mesh");

Anyway, those are my thoughts. Don't know if we want to mess with build scripts.

[Geemili]

Could we make it a generic so that the user can decide?

Another thought I had is making a build script that takes a resource file and bakes the strings into integers, similar to how android does it. The build script could generate a bunch of environment variables like AMETHYST_RESOURCE_ID_sphere_mesh=123. After the environment is generated, the user can just include using:

let sphere_resource = env!("AMETHYST_RESOURCE_ID_sphere_mesh");

Or even a custom macro so we can omit the prefix:

let sphere_resource = resource!("sphere_mesh");

Anyway, those are my thoughts. Don't know if we want to mess with build scripts.

[bjadamson]

I like this, I think I can put a builder in front of this and make it general.

[bjadamson]

I like this, I think I can put a builder in front of this and make it general.

[Geemili]

Another thought: If we're going to deal with build scripts, we could just generate a "resources.rs" that contains all the resource constants. It would mean that all the env!() macros wouldn't need a u32::from_str().unwrap() surrounding them.

[Geemili]

Another thought: If we're going to deal with build scripts, we could just generate a "resources.rs" that contains all the resource constants. It would mean that all the env!() macros wouldn't need a u32::from_str().unwrap() surrounding them.

[Emilgardis]

One way to have both i64's and String is to with #90 have each function take id: T where T: Into<*Id>
The one problem I can see are collisions. One way to fix this is to feature-flag i64 to only have one enabled, but I'm playing around trying to find a good solution.

[Emilgardis]

One way to have both i64's and String is to with #90 have each function take id: T where T: Into<*Id>
The one problem I can see are collisions. One way to fix this is to feature-flag i64 to only have one enabled, but I'm playing around trying to find a good solution.

[bjadamson]

Another thought, maybe it makes sense to always support static str& but String explicitly separately?

[bjadamson]

Another thought, maybe it makes sense to always support static str& but String explicitly separately?

[ebkalderon]

The asset manager has changed significantly since the creation of this issue and uses &str as opposed to fat strings. I think I'll close this issue as it is no longer relevant.

[ebkalderon]

The asset manager has changed significantly since the creation of this issue and uses &str as opposed to fat strings. I think I'll close this issue as it is no longer relevant.