Conversation
Saves a ton of 64k allocs
|
|
||
| if ack.SeqNo != ping.SeqNo { | ||
| return false, fmt.Errorf("Sequence number from ack (%d) doesn't match ping (%d)", ack.SeqNo, ping.SeqNo, LogConn(conn)) | ||
| return false, fmt.Errorf("Sequence number from ack (%d) doesn't match ping (%d) %s", ack.SeqNo, ping.SeqNo, LogConn(conn)) |
There was a problem hiding this comment.
Updating Go found all these issues in the existing code
mihaitodor
left a comment
There was a problem hiding this comment.
Awesome! Nice find. Looks like this should be fixed upstream too: https://github.com/hashicorp/memberlist/blob/696ff46201c1b64d31b60d57971d07d8cf15df7a/util.go#L240
Not sure if relevant, but I noticed this error is unchecked with golangci-lint:
Line 354 in cfac2b5
Otherwise ![]()
@mihaitodor thanks, yeah I had looked at the upstream first and saw they hadn't done anything to improve this. Because the upstream SWIM implementation does nowhere near as much gossiping, I suspect that this is not as much of an issue. |
|
Sadly, looks like this does need a pooling setup. Appears to be used in a goroutine. |
|
Ugh... You know, I was thinking to ask about that when I reviewed it. I recall implementing something like that somewhere, but I can't recall where. |
A busy Sidecar is spending like 6% of its CPU time allocating LZW writers! These had a dumb interface in the stdlib and it was improved in 1.17 with the addition of a
Reset()function. This update re-uses both thebytes.Bufferand thelzw.Writerwhich should save a lot of allocs! This is only called from a loop over a channel so there should not be synchronization issues.