search

Picodes / 4naly3er

Static smart contract code 4naly3er
https://github.com/Picodes/4naly3er
GNU General Public License v3.0
492 stars 134 forks source link

`calldataViewFunctions` may encourage gas inefficiency #14

Open CodeSandwich opened 1 year ago

CodeSandwich commented 1 year ago

The calldataViewFunctions flags all memory parameters as gas inefficient if they aren't modified. This isn't always the case, memory arguments are often cheaper than calldata. This is because calldata is not trusted by Solidity and each access does many sanity checks while memory arguments are sanity checked only once, when loading. I've seen a gas usage drop after switching from calldata to memory in the contracts I've been working on and it even has an issue in Solidity repo, which doesn't seem to be ever solved due to calldata arguments needing the sanity checks: https://github.com/ethereum/solidity/issues/12103.

IllIllI000 commented 1 year ago

the issue referenced mentions that memory is cheaper if you access more than once, but if you're accessing more than once, you should be using a stack variable anyway. I'll try to come up with some test cases to tease out when it make sense to use one vs the other

Picodes commented 1 year ago

@IllIllI000 I am definitely interested in such test cases

IllIllI000 commented 1 year ago

please remind me after March 25th (GMX contest end)

InfectedIsm commented 1 year ago

@IllIllI000

⏰ it's after March 25th (sorry was reading the issues and maybe you still want to be reminded lol)

IllIllI000 commented 1 year ago

Ah, thanks I did indeed forget. Still busy with other work, but won't submit this finding again until I have it worked out

IllIllI000 commented 10 months ago

@CodeSandwich do you have an example where memory is cheaper than calldata when the array isn't an array where each array value is smaller than a word? That's the only type of scenario for which I was able to reproduce it: https://gist.github.com/IllIllI000/2ac9a647be917f58ffe5baa2cecbbc42

CodeSandwich commented 10 months ago

@IllIllI000 I think that your results are spot on, memory only makes sense for types smaller than the word.

I've tried doing some benchmarks myself and for arrays of uint256 calldata was always cheaper no matter how many times the array was accessed, and for uint248 or smaller memory was always cheaper. It's also true for bytes, they are marginally cheaper as calldata. Out of curiosity I've tried uint256[][], and still calldata is cheaper.