`calldataViewFunctions` may encourage gas inefficiency
CodeSandwich opened this issue · 7 comments
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: ethereum/solidity#12103.
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
@IllIllI000 I am definitely interested in such test cases
please remind me after March 25th (GMX contest end)
⏰ it's after March 25th (sorry was reading the issues and maybe you still want to be reminded lol)
Ah, thanks I did indeed forget. Still busy with other work, but won't submit this finding again until I have it worked out
@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
@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.