Skip to content
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

Make Governance Proposal Queues more efficient #2637

Closed
sunnya97 opened this issue Oct 31, 2018 · 3 comments · Fixed by #2638
Closed

Make Governance Proposal Queues more efficient #2637

sunnya97 opened this issue Oct 31, 2018 · 3 comments · Fixed by #2638
Assignees
Labels

Comments

@sunnya97
Copy link
Member

As noticed by @mossid in #2613

we don't have to unmarshal the whole proposal each time(consider the case where a TextProposal has a very long description).

The inactive and active proposal queues in governance currently unmarshal and marshal the entire queue of proposals. These queues should be updated to use a more advanced queue such as the ones used in staking unbonding and redelegation queues.

@alexanderbez
Copy link
Contributor

These queues should be updated to use a more advanced queue such as the ones used in staking unbonding and redelegation queues.

@sunnya97 can you elaborate please?

@sunnya97
Copy link
Member Author

sunnya97 commented Nov 1, 2018

Essentially, the current queue in governance just puts all of the ProposalIDs in a slice that is []ProposalID. In every EndBlocker, it unmarshals the entire slice, gets the first element, Gets the Proposal, checks if the Proposal is expired, and if so Pops it from the queue and executes.

The iterator based queue, makes clever use of the sdk.Iterator in order to only get the list of ProposalIDs that expire by the current BlockTime. This way, you're not unmarshaling the entire queue ([]ProposalID) and first Proposal every endblocker, just to see if needs to be popped.

Also, another benefit is that this queue makes it easier to insert elements into the middle of the queue, rather that just at the end. This will be useful in the case where we want DepositPeriod or VotingPeriod to have a potential range (like maybe there is a minimum voting period and a maximum, but the proposal creator can choose the length within those bounds).

@alexanderbez
Copy link
Contributor

Got it. Sounds like a great improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants