-
Notifications
You must be signed in to change notification settings - Fork 11.9k
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
Optimize Ownable and Pausable modifiers' size impact #3347
Optimize Ownable and Pausable modifiers' size impact #3347
Conversation
EDIT: solidity version updated to 0.8.14 For the
Here are the deployment gas cost:
Oddly enough, each additional function is not really cheaper with the new version, but the base cost is cheaper |
With solidity 0.8.14 and optimisations on (200)
Its actually costing more gas to have the internal function! |
Note that changing visibility between internal and private does NOT change the deployment cost. |
I'm afk all day, so I'll take another look when I am at a computer. That being said, regarding the first set of tests, objectively, Ownable has less code than OwnableV2, so it doesn't make much sense to me that the base contract would be larger for Ownable than it is for OwnableV2. Definitely surprising to me that the behavior we are seeing in those tests is literally the exact opposite of what we should expect from the code. Is it possible the tests are not representing the correct contracts? If not, maybe there is a nuance between gas cost and contract size I'm not understanding. |
There is a nuance between gas cost and contract size. IMO what the devs really care about is deployment gas costs.
In terms of number of lines yes, but not in terms of functionality. If functionalities are equal, and if the gas cost is the same (or very close) I would go for the more readable version, which is the current one. Adding code, that reduces readability, hoping to save gas, not saving gas, and arguing it's normal because "there is more code" is not the way we want to go. |
To be clear, the argument is not "there is more code" the argument is that the new version can reduce contract size significantly (depending on usage of modifier). If deployment gas cost is what we are optimizing for then it would seem from your tests that it would make sense to not introduce the change. |
That is what I'm trying to show ... and so far I'm failing. What test would you run to verify that claim? |
When calling
|
To verify the claim I would just look at the size of a compiled contract that uses the modifier, we should expect the compiled size to increase by more for each function in a contract that uses the original modifier and the increase should be less for a contract that uses the new modifier. The idea here being that because the modifier literally has less code, when it is inlined in compilation, it will increase the contract size by less than it did originally. Regarding the gas cost at run time, we should expect the new modifier to be slightly more expensive. I'm sorry I'm afk, but will be happy to help when I'm at a computer. |
That is also what I would expect ... but if you take my T1 and T2 example from above (here), T1 object is 348 bytes, and T2 is 354 bytes. |
My results have been biased by the function being empty, and the compiler possibly merging them. If I put some code in the function's body, then I observe the expected behavior.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's go!
Fixes #3222
Affects:
contracts/access/Ownable.sol
contracts/security/Pausable.sol
Changes:
PR Checklist