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

proto: deduplicate consensus params #9287

Merged
merged 9 commits into from
Aug 22, 2022
Merged

Conversation

cmwaters
Copy link
Contributor

@cmwaters cmwaters commented Aug 18, 2022

proto files contain two identical cosnensus params. One in types and the other in abci. This PR aims at consolidating the two. Port of #5994

This PR also includes the depracation of TimeIotaMs (ref: #5792)

@cmwaters cmwaters changed the base branch from main to feature/abci++ppp August 18, 2022 09:49
@cmwaters cmwaters marked this pull request as ready for review August 18, 2022 09:50
@cmwaters cmwaters requested a review from a team August 18, 2022 09:51
@cmwaters cmwaters mentioned this pull request Aug 18, 2022
39 tasks
@sergio-mena
Copy link
Contributor

Good catch. @williambanfield and I had noticed that ConsensusParams had moved from abci to types somewhere after v0.34.x, and decided to leave ConsensusParams and BlockParams in abci for simplicity. I was not aware that ConsensusParams was also present in types in this branch.

My question is: what was the rationale in the first place to move ConsensusParams from abci to types? (looked up the PR, but no info)

@sergio-mena
Copy link
Contributor

Follow up: I was intrigued by this duplication, and how it landed on the feature/abci++ppp branch.
Did some digging and realized this duplication is ALSO on v0.34.x, not sure fixing it there entails a risk low enough, though.

@williambanfield
Copy link
Contributor

Appears that this was originally done during v0.35 in this pull request: #5987

There is no rationale present on that pull request so it's difficult to understand why it was done.

@williambanfield
Copy link
Contributor

@sergio-mena I don't see this as being present in v0.34.x

ConsensusParams *ConsensusParams `protobuf:"bytes,3,opt,name=consensus_params,json=consensusParams,proto3" json:"consensus_params,omitempty"`

Copy link
Contributor

@williambanfield williambanfield left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs a changelog entry, will break in-process apps.

@sergio-mena
Copy link
Contributor

I have added this PR to the Tendermint project, so people have visibility from the project board.

@sergio-mena sergio-mena mentioned this pull request Aug 18, 2022
35 tasks
@sergio-mena
Copy link
Contributor

I also added a checkbox in #9053 (final adjustments) with a reference to this PR

@sergio-mena
Copy link
Contributor

sergio-mena commented Aug 18, 2022

@sergio-mena I don't see this as being present in v0.34.x

@williambanfield not sure I get what you mean. Do you mean that protos and generated code don't match in v0.34.x?

@williambanfield
Copy link
Contributor

williambanfield commented Aug 18, 2022

@sergio-mena
sigh I misread. I thought you were saying that the change present in v0.35 was also present in v0.34 but that's not what you were saying.

Comment on lines 2272 to 2273
// TODO: We should remove next line in case we don't vote for v in case cs.ProposalBlock == nil,
// even if cs.LockedBlock != nil. See https://docs.tendermint.com/master/spec/.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this comment now stale too?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's in v0.36.x so I assume not

state/store.go Outdated
Comment on lines 530 to 534
// Allocate empty Consensus params at compile time to avoid multiple allocations during runtime
var (
empty = types.ConsensusParams{}
emptypb = tmproto.ConsensusParams{}
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this copped from somewhere else? It seems dubious that this would actually save any measurable memory or time, and just opens us up to weird testing flukes. If there's a good way to omit this pattern, I would.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it's copied from the original PR

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with Sam. This is saving us almost nothing. As far as I know, global variables are not allocated at compile time. I'm not really sure I know what that means. They're allocated when the program starts. This just means they're allocated only once which really saves us so little here.

Copy link
Contributor

@sergio-mena sergio-mena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

state/store.go Outdated
Comment on lines 301 to 302
var params types.ConsensusParams
params, err = store.LoadConsensusParams(h)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
var params types.ConsensusParams
params, err = store.LoadConsensusParams(h)
params, err := store.LoadConsensusParams(h)

Not sure the separated variable declaration gets us anything.

state/store.go Outdated
Comment on lines 530 to 534
// Allocate empty Consensus params at compile time to avoid multiple allocations during runtime
var (
empty = types.ConsensusParams{}
emptypb = tmproto.ConsensusParams{}
)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with Sam. This is saving us almost nothing. As far as I know, global variables are not allocated at compile time. I'm not really sure I know what that means. They're allocated when the program starts. This just means they're allocated only once which really saves us so little here.

consensus/state.go Outdated Show resolved Hide resolved
Copy link
Contributor

@williambanfield williambanfield left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all minor points, otherwise looks good.

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

Successfully merging this pull request may close these issues.

None yet

4 participants