To avoid storage variables and mappings as much as possible

[EmperorOrokuSaki]

Following the discussion here, I have decided to write a more detailed discussion post to explain the reasons behind my comment.

Using storage vars and mappings and retrieving them in non-view functions cost a lot of gas. In fact, the first read of a storage slot that has not been accessed before costs 2100 more gas units than the next reads in the same transaction. Each following storage slot read costs 100 gas units. On the other hand, each memory slot read and write expenses three units of gas, a way cheaper option than storage. (Check the sload opcode description here)

The comment that was made on #184 is an example of this. Declaring a uint256 -> uint256 mapping that uses storage slots is not very cost-friendly, especially when compared to the alternative of storing the value in the App struct which opens the door to struct packing possibilities as well. Since the App struct already has uint256 values and having this new value adjacent to them helps the storage costs considerably.

EVM stores everything in its storage slots sequentially, so having multiple data types within a struct with different storage needs can be optimized by making sure all fields and types are ordered in a way to maximize efficiency.

[jsonsivar]

Was talking to @daltoncoder about this and we came to an idea like what if we use the app struct (or structs in general) for any non string or dynamic fields and then use the mappings for string fields. Maybe we need to POC that to see the gains but it sounded like a good balance.

Also I think this topic affects this one too #163.

[zoruka]

What if we nest a struct in another? So we could have an interface with a given struct and in the main contract a struct that have this struct inside. Would require to check how this would perform in struct packing.