2

I used to think that each read/write access to storage account for the same weight. But does it ? Or is there a linear relation between the (encoded) size of the data accessed and the price to pay ?

Does a read on a huge struct account for for the same as a read of a simple u8 ? What about vectors, does it cost more to read/write a huge vector that a small one ?

In the same vein, does removing a value, a key or an entire suffix from count as a write ? We are freeing space their so I expect it not to, but I couldn't find a clear explanation.

Improve this question
3
  • 1
    this is a really nice video from Shawn Tabrizi, check 16:30 youtu.be/kKKOL20FdII
    – Decentration
    Jun 11, 2022 at 21:03
  • 1
    Its 0(log n) to read, where n is nodes in the trie, so a large struct to access a u8 will be more to read, but it’s useful if you need to access and/or update the other data in the struct at the same time. But if you only need to read and update the one value better to store by itself. Less nodes to read (… i think)
    – Decentration
    Jun 11, 2022 at 21:28
  • 1
    I will probably write an answer here as well, but in the meantime you can have a look at this analysis substrate.stackexchange.com/questions/525/…
    – Oliver Tale-Yazdi
    Jun 12, 2022 at 0:06

1 Answer 1

Reset to default
4

In Substrate we make some assumptions and simplifications to keep the equations simple.
It does not take longer to read a larger value in general. This is due to the database backend chunking the data. There are jumps in the timing as described in the answer that I already linked above. There is a correlation between item size and access time, but its not linear.

Our observation was that most of the values that are currently being read/written on-chain are account data structs with 80 byte in them.
We then developed a benchmarking system which reads and writes the complete chain snapshot and collects the time that it takes for each value. The usage is documented here.
The average results are calculated and used as constants for reading or writing a single value.
This has the advantage of being very simple to calculate. You have to keep in mind that every formula for calculating the weight needs to be really cheap, a constant is therefore perfect.

The downside is that it needs to be regularly updated to represent the average read and write weight. We currently add 15% to the calculated constants to adjust for a lag of updating them.

If you want to optimize the weight of your Pallet, you have to find the sweet spot between number of storage accesses and item size.
The item size is not important right now, but will be important once Weights V2 hits.
This effectively prevents you from putting all the data in one huge storage item because of the huge PoV size this would inflict.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.