How RAM was allocated in dapp and how to optimize the table?

Question

We are doing dapp development on EOS. And it seems cost more ram than we evaluated.

How much ram will be used when stored a table record? And how to optimize the table structure to save the ram?

See the example below, how much ram will be used when create a record? and how to optimize it to save ram?

struct producer_info {
  account_name          owner;
  double                total_votes = 0;
  eosio::public_key     producer_key; /// a packed public key object
  bool                  is_active = true;
  std::string           url;
  uint32_t              unpaid_blocks = 0;
  uint64_t              last_claim_time = 0;
  uint16_t              location = 0;


  uint64_t primary_key()const { return owner;                                   }
  double   by_votes()const    { return is_active ? -total_votes : total_votes;  }
  bool     active()const      { return is_active;                               }
  void     deactivate()       { producer_key = public_key(); is_active = false; }

  // explicit serialization macro is not necessary, used here only to improve compilation time
  EOSLIB_SERIALIZE( producer_info, (owner)(total_votes)(producer_key)(is_active)(url)
                    (unpaid_blocks)(last_claim_time)(location) )

};

Answer 1

I don't know how you calculated your contracts RAM consumption, but the devil lies in the details.

Index Basics

Using an index is always connected to sacrify some memory for speed. This is a well researched database topic. An index is an optimized datastructure with some overhead which organizes data records e.g. in an tree like structure. You can read more about it here.

For [...] example consider the index in the back of a book. It’s pretty simple to use. Just scan for the subject you’re interested in, note, and flip to those pages in your book. [But you will have extra pages.]

Based on your code I guess that you also use secondary indices which will increase your RAM usage aswell.

---

Calculation

So the RAM needed for storing will be:

number_of_tuples * size_of(struct) + overhead_by_primary_index + overhead_by_secondary_index_0 + ... + overhead_by_secondary_index_n

---

Optimization

Looking at your code you could also evaluate your structs datatypes and necessary secondary indices.

Do you really need a double for total_votes or would an uint16_t (by multiplying by x*10 and cutting the last digits) be enough? Could the last_claim_time also be an uint32_t?

Also is your by_votes() index really necessary? You could also sort inside the action call, which will take longer but save RAM.

Like I said the devil lies in the details. Possible pitfalls may also be working with pointers and references.