-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Use storage::append
in the implementation of the storage types
#5889
Conversation
@@ -526,47 +526,47 @@ mod test_append_and_len { | |||
#[test] | |||
fn append_works() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kill + append
overwrite + append
would be nice additions to this test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overwrite + append
Is done below inappend_overwrites_invalid_data
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added kill + append
/bench import/full |
Finished benchmark for branch: bkchr-storage-append-improvements Benchmark: Import Benchmark (Full block with wasm, for weights validation) Master: 1333.89 ms |
polkadot not building? |
Yeah, already working on a companion. |
* Companion pr for Substrate paritytech#5889 * Update Substrate ref
This pr moves all the
append_*
functions to use the newstorage::append
functionality. This should improve the performance of all these calls. Besides that the host implementation is changed to use theEncodeAppend
fromparity-scale-codec
instead of copying it.The implementation comes with some "disadvantages":
append
will overwrite it and also ignores any default value set in the runtime. Sadly there isn't a better solution for this, but we also should teach people that vectors etc should not get any special default values.append
one item at a time. Up to now, there was only one call toappend
that tried to append more items.