-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Avoid some clone when creating keys to use in StorageMap methods #1876
Comments
note: that could also be useful for tuple values |
So you just propose to take the keys by reference? FWIW |
We already take key and value by reference, the thing is that EDIT: Yes in a way I propose to be able to take inner type of a tuple (or anything if user defined the trait for his own structs) by reference |
Just fyi Rust has a long history around roughly this problem: rust-lang/rfcs#1769 https://internals.rust-lang.org/t/pre-rfc-abandonning-morals-in-the-name-of-performance-the-raw-entry-api/7043 |
impl<'a, T: Encode + 'a> SameEncodeAs<T> for &'a T {}
impl<A, B, X, Y> SameEncodeAs<(X, Y)> for (A, B) where A: SameEncodeAs<X>, B: SameEncodeAs<Y> {}
... might work better because then you can mix and match. |
Quite interesting that I came up with a very similar api some months later, without remembering your proposal :D |
When we create a StorageMap with a tuple for example
(T::AccountId, u64)
here in substrate kitties then to use it we often need to clone AccountId (it doesn't implements Copy) like hereIn this example it is not an issue as AccountId is meant to be an integer such as u64 and clone it is probably same cost as referencing it.
But in other situation it could be an issue. I don't know if such situations exist though (long key that shouldn't be cloned, (caching there encoding, I don't know)).
A solution I have in mind for that is using a trait SameEncodingAs as such:
a partial implement is then (based on ebe4c97):
The text was updated successfully, but these errors were encountered: