-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
raft: don't allocate slice and sort on every commit #8689
Conversation
will this bring in an observable perf improvement for cockroachdb? |
I doubt it will be observable, but saving 2 allocations (the slice and the |
Here's a
The change is also addressing a TODO, so we should remove that TODO if we don't want to optimize this. |
@nvanbenschoten can you rebase? |
@siddontang can you take a look? |
b5b9d61
to
1f08a33
Compare
@xiang90 I just rebased this off master. |
@xiang90 ok |
I suggest using a new PR for the change of Raft learner. Rest LGTM |
Codecov Report
@@ Coverage Diff @@
## master #8689 +/- ##
==========================================
+ Coverage 69.17% 75.94% +6.77%
==========================================
Files 386 359 -27
Lines 35891 29961 -5930
==========================================
- Hits 24827 22755 -2072
+ Misses 9264 5625 -3639
+ Partials 1800 1581 -219
Continue to review full report at Codecov.
|
@siddontang TFTR. I pulled the second commit out into #9088. |
1f08a33
to
ee5a1ae
Compare
raft/raft.go
Outdated
@@ -547,13 +548,23 @@ func (r *raft) bcastHeartbeatWithCtx(ctx []byte) { | |||
// the commit index changed (in which case the caller should call | |||
// r.bcastAppend). | |||
func (r *raft) maybeCommit() bool { | |||
// TODO(bmizerany): optimize.. Currently naive | |||
mis := make(uint64Slice, 0, len(r.prs)) | |||
if cap(r.matchBuf) < len(r.prs) { |
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.
probably document this optimization for avoiding allocations on slice creating and sorting.
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.
Done.
raft/raft.go
Outdated
} | ||
mis := r.matchBuf[:len(r.prs)] | ||
idx := 0 | ||
sorted := true | ||
for _, p := range r.prs { |
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.
it seems that it is low chance that prs happens to be sorted? not sure if this optimization makes sense.
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.
In TiKV, we still sort it every time. maybe we can write a benchmark for this.
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.
Yeah the change that this is sorted is low - 1/(n!)
if we assume that map iteration is always random. Probably not worth the extra complexity to this function. Removed.
ee5a1ae
to
0a415cf
Compare
Reviving this after seeing this allocation account for |
lgtm. defer to @siddontang or @gyuho |
I am on vacation till Friday. Will review by Monday. Thanks! |
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. Thanks for optimization @nvanbenschoten!
This picks up etcd-io/etcd#8689. Release note: None
27998: Pick up etcd-io/etcd#8689 r=nvanbenschoten a=nvanbenschoten This picks up etcd-io/etcd#8689. Release note: None 28002: storage: avoid double lock in tryGetOrCreateReplica r=nvanbenschoten a=nvanbenschoten Before this change, `tryGetOrCreateReplica` was RLocking, checking an uncommon condition, then Locking. This was unnecessary and made the code look strange. It also resulted in an extra RLock in the exceptionally common case where the Replica was not destroyed. This change fixes this by collapsing the destroyStatus check into the main critical section. There's no real expected performance improvement here, this is mostly just for cleaner code. Release note: None Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
No description provided.