-
Notifications
You must be signed in to change notification settings - Fork 857
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
optimization constant time #65
base: main
Are you sure you want to change the base?
Conversation
WalkthroughThe update introduces a new constant Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
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.
Review Status
Actionable comments generated: 2
Configuration used: CodeRabbit UI
Files selected for processing (2)
- contracts/XCounter.sol (2 hunks)
- contracts/XCounterUC.sol (2 hunks)
Additional comments: 2
contracts/XCounter.sol (1)
- 12-12: The introduction of
CONST_TIME
as an immutable uint64 is a good practice for gas optimization. The choice of type and the immutable keyword are appropriate for constants that do not change.contracts/XCounterUC.sol (1)
- 12-12: The introduction of
CONST_TIME
as an immutable uint64 is a good practice for gas optimization. The choice of type and the immutable keyword are appropriate for constants that do not change.
@@ -37,7 +38,7 @@ contract XCounter is CustomChanIbcApp { | |||
bytes memory payload = abi.encode(msg.sender); | |||
|
|||
// setting the timeout timestamp at 10h from now | |||
uint64 timeoutTimestamp = uint64((block.timestamp + timeoutSeconds) * 1000000000); | |||
uint64 timeoutTimestamp = uint64((block.timestamp + timeoutSeconds) * CONST_TIME); |
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.
The calculation of timeoutTimestamp
seems to misunderstand the purpose of CONST_TIME
. Multiplying block.timestamp + timeoutSeconds
by CONST_TIME
does not align with the typical use of a timeout timestamp. If CONST_TIME
is meant to represent a constant duration, it should likely be added to, not multiplied by, the current timestamp and timeout period.
- uint64 timeoutTimestamp = uint64((block.timestamp + timeoutSeconds) * CONST_TIME);
+ uint64 timeoutTimestamp = uint64(block.timestamp + (timeoutSeconds * CONST_TIME));
Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
uint64 timeoutTimestamp = uint64((block.timestamp + timeoutSeconds) * CONST_TIME); | |
uint64 timeoutTimestamp = uint64(block.timestamp + (timeoutSeconds * CONST_TIME)); |
@@ -32,7 +34,7 @@ contract XCounterUC is UniversalChanIbcApp { | |||
increment(); | |||
bytes memory payload = abi.encode(msg.sender, counter); | |||
|
|||
uint64 timeoutTimestamp = uint64((block.timestamp + timeoutSeconds) * 1000000000); | |||
uint64 timeoutTimestamp = uint64((block.timestamp + timeoutSeconds) * CONST_TIME); |
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.
The calculation of timeoutTimestamp
seems to misunderstand the purpose of CONST_TIME
. Multiplying block.timestamp + timeoutSeconds
by CONST_TIME
does not align with the typical use of a timeout timestamp. If CONST_TIME
is meant to represent a constant duration, it should likely be added to, not multiplied by, the current timestamp and timeout period.
- uint64 timeoutTimestamp = uint64((block.timestamp + timeoutSeconds) * CONST_TIME);
+ uint64 timeoutTimestamp = uint64(block.timestamp + (timeoutSeconds * CONST_TIME));
Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
uint64 timeoutTimestamp = uint64((block.timestamp + timeoutSeconds) * CONST_TIME); | |
uint64 timeoutTimestamp = uint64(block.timestamp + (timeoutSeconds * CONST_TIME)); |
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.
Hey @deepface19 thanks for your contribution. I understand the idea to set some constant for conversion. However, if we were to optimize I wonder if this is the place to do it.
I'm thinking it could be better instead to add a helper function to convert timeout in seconds to its nanoseconds value in the vibc-core-smart-contracts repo here.
I'll discuss with the team
optimization constant time.
make public constant time.
Summary by CodeRabbit
timeoutTimestamp
in specific functions, enhancing the efficiency of operations.