New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gas Optimizations #277
Comments
This was a very detailed report - thanks.
Agree, but optimizing for admin-only functions is not a goal. Keeping as is for simplicity.
Agree, fixed!
Agree, fixed.
Agree, fixed.
Agree, fixed.
Invalid - casting does not cause an SLOAD
Invalid - the data here is a bool which cannot be storaged as a storage variable.
Potentially valid, but keeping the code as is for readability (so we can keep the delete keyword here).
Won't fix. This function is shared with another out-of-scope contract.
Valid & will fix. This saves ~50 gas on
Agree and will fix.
May be theoretically valid, but won't fix. I tested this: gas-reporter and our gas-stories suite is reporting a small regression using this technique. It also hurts readability a bit so we wouldn't want to include it unless it was a clear win.
Agree and will fix.
Invalid. We tested the recommendation and got the following results:
Valid for
Won't fix - I still like the modifier for readability.
Potentially valid but won't fix. This is uint32 to allow packing storage for a significant gas savings. Accepting the input as uint256 would incur additional overhead in checking for overflow before saving these values. Other inputs are logically limited to the size exposed, huge values cannot be used. Accepting the input as uint256 would incur additional overhead in checking for overflow before using these values.
Agree but won't fix. We use up to 64 bytes, aiming to respect the incremental cost but 32 bytes is a bit too short to provide descriptive error messages for our users.
Agree but won't fix at this time. We use these in the market but not in collections. Unfortunately custom errors are still not as good of an experience for users (e.g. on etherscan). We used them in the market originally because we were nearing the max contract size limit and this was a good way to reduce the bytecode. We'll consider this in the future as tooling continues to improve. |
See the markdown file with the details of this report here.
The text was updated successfully, but these errors were encountered: