Using memory location for strcuts/arrays will result in gas savings
The addToPool
function uses pools[poolId]
multiple times within its execution, when a certain pool needs to be retrieved from the pools mapping. It accesses the pools mapping each time, which is leading to redundant storage reads. This is leading to less gas-efficient code.
There are 4 instances of this problem and all of them are located in the Lender.sol
contract:
https://github.com/Cyfrin/2023-07-beedle/blob/658e046bda8b010a5b82d2d85e824f3823602d27/src/Lender.sol#L178C1-L192C6
https://github.com/Cyfrin/2023-07-beedle/blob/658e046bda8b010a5b82d2d85e824f3823602d27/src/Lender.sol#L194C1-L205C1
https://github.com/Cyfrin/2023-07-beedle/blob/658e046bda8b010a5b82d2d85e824f3823602d27/src/Lender.sol#L206C1-L215C6
https://github.com/Cyfrin/2023-07-beedle/blob/658e046bda8b010a5b82d2d85e824f3823602d27/src/Lender.sol#L217C1-L226C6
There is no caching for the pools[poolId
struct in memory, which can result in increased gas consumption. This problem can lead to higher transaction and execution costs for each user who interacts with the given contract and its functionality.
Manual Review
In the current state of the contract, the storage variable is retrieved multiple times, which will result in higher gas consumption. We can solve this by declaring a struct variable with a memory location to save gas when invoking variables from the struct and storing a temporary copy. This way the contract can avoid repeated storage reads, leading to significant gas savings.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.