Before going deep into the topic let us know about solidity.
What is Solidity
Solidity is a brand new programming language released in 2015 developed by Ethereum, the second largest cryptocurrency platform by market capitalization. Solidity is an object-oriented high-level language for handling smart contracts. So if you want to become a blockchain developer for creating smart contracts, you should get used to it. It is impressed by Python, C++, and JavaScript.
Coding in Solidity is different than in other languages. Here are some tips and tricks to keep your gas bills low.
Mapping is Cheaper than Arrays! in Most Cases
Solidity is the first language where mapping is cheaper than arrays! This is how EVM works. Arrays are stored as allocations instead of being stored sequentially in memory. Arrays can be packed, but mappings cannot. So if you have small elements like uint8 that can be packed together, it's cheaper to use an array. You can't get the length of the mapping or parse all its elements, so depending on your use case you may be forced to use an array even if you need more gas.
Use the Short Circuit Rule to Your Advantage
When using disjunctive (||) and conjunctive (&&), order functions correctly for optimal gas usage. Using disjunction (OR) saves gas because if the first function is true, the second function will not be executed. In disjunction (AND), if the first function evaluates to false, the second function is not evaluated. Therefore, you should reorder the functions appropriately in your Solidity code to reduce the chances of having to evaluate a second function. Solidity allows multiple small variables to be packed into slots, but if you're defining a single variable and it can't be packed, it's best to use uint256 instead of uint8.
Pack Your Variables
With Ethereum, you have to pay gas fees for each storage space you use. Slots are 256 bits and can contain as many variables as you like. Packing is done automatically by the Solidity compiler and optimizer. You only need to declare packable functions one at a time. Solidity stands apart from other languages in these aspects. For optimization in other languages, "‹"‹things such as variable order were less important. Also note that structs, mappings, and arrays always start in a new slot.
Not All Items can be Packed
Unable to pack items into memory and recall data. Using smaller variables in function calls and memory does not sacrifice robustness.
Do Not Change Save Data
Changing memory data consumes more gas than changing memory or stack variables, so memory variables should be updated after every calculation instead of updating after every calculation.
Reduce Outside Calls
Every time you call an external contract, a lot of gas is generated. To optimize gas consumption, it's better to call a function and return all the data you need rather than calling a separate function for each data. This may go against best programming practices in other languages, but it's exceptionally robust.
Use External Function Modifiers
For all public functions, input parameters are automatically copied into memory and gassed. If the function is only called externally, it must be explicitly marked as external. External function parameters are not copied into memory and are read directly from the call data. If your function has huge input parameters, a small tweak to the Solidity code can save a lot of gas.
Delete Unnecessary Variables
Ethereum allows you to get gas refunds by freeing up space. When a variable is no longer needed, it should be deleted or set to a default value using the delete keyword provided by solidity. This also helps keep the size of the blockchain small.
Uint8 is Not Always Cheaper than Uint256
The EVM only works 32 bytes/256 bits at a time. This means that if you use uint8, EVM has to first convert it into uint256 to work with, and conversion costs extra gas. You might be wondering what are the developers thinking. So why did they create smaller variables? The answer is in the packaging.
Use Bytes 32 Instead of Strings/Bytes
If your data can fit in 32 bytes, you should use byte 32 data types instead of bytes or strings. Basically fixed sizes with variable strength are cheaper than variable sizes.