TBH, I find the whole premise a bit silly. The one use case the original video talks about there this might be a good idea is when you have something like a MonsterId(String), and argues for MonsterId(Arc<str>) instead - which I think is an anti-pattern. Use MonsterId(usize) and it becomes far cheaper to clone than even an Arc<str>. There is no need to lug around strings as ids - which are presumably going to be used to look up values in a hashmap or similar (which again, I would suspect it is faster to has a usize than a string of any type).
Most of the rest of the time cloning a string is not a huge issue or if it is &str is often good enough. I find it rare that you would ever need the clone performance and multiple ownership of a Arc<str>.
There are also crates like smallstring, smallstr etc, that are stack allocated strings up to a certain limit before they start allocating. Which would be worth a look at and see how they preform compared to Arc or String. Since most things I bet they were using Strings for would fit inside these types just find without the extra allocation.
It is a neat trick to have in your toolbag - but not the first thing I would jump for when dealing with strings.
which are presumably going to be used to look up values in a hashmap or similar (which again, I would suspect it is faster to has a usize than a string of any type).
Yeah, for any primitive types, you can just use the value itself as the hash value here. So, effectively a noop. I assume, Rust's implementation makes use of this...
TBH, I find the whole premise a bit silly. The one use case the original video talks about there this might be a good idea is when you have something like a
MonsterId(String), and argues forMonsterId(Arc<str>)instead - which I think is an anti-pattern. UseMonsterId(usize)and it becomes far cheaper to clone than even anArc<str>. There is no need to lug around strings as ids - which are presumably going to be used to look up values in a hashmap or similar (which again, I would suspect it is faster to has a usize than a string of any type).Most of the rest of the time cloning a string is not a huge issue or if it is &str is often good enough. I find it rare that you would ever need the clone performance and multiple ownership of a
Arc<str>.There are also crates like smallstring, smallstr etc, that are stack allocated strings up to a certain limit before they start allocating. Which would be worth a look at and see how they preform compared to Arc or String. Since most things I bet they were using Strings for would fit inside these types just find without the extra allocation.
It is a neat trick to have in your toolbag - but not the first thing I would jump for when dealing with strings.
Yeah, for any primitive types, you can just use the value itself as the hash value here. So, effectively a noop. I assume, Rust's implementation makes use of this...