fix(p2p): make PeerSet.Remove more efficient #2159
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
0eeb681 to
58a353f
Compare
melekes
reviewed
Jan 28, 2024
58a353f to
4319780
Compare
melekes
reviewed
Jan 29, 2024
This change makes PeerSet.Remove much more efficient simply by using more idiomatic Go re-slicing to avoid the prior mechanisms of creating fresh peer set lists on just a single remove. While here also added a remedy for a found bug cometbft#2158 due to an abstraction that returns a stale slice to its caller in Switch.OnStop. Benchmark results: ```shell $ benchstat before.txt after.txt name old time/op new time/op delta PeerSetRemoveOne-8 90.5µs ± 4% 95.9µs ±13% ~ (p=0.218 n=10+10) PeerSetRemoveMany-8 1.58ms ± 4% 1.50ms ± 1% -4.98% (p=0.000 n=10+8) name old alloc/op new alloc/op delta PeerSetRemoveOne-8 8.48kB ± 0% 7.92kB ± 0% -6.60% (p=0.000 n=10+10) PeerSetRemoveMany-8 149kB ± 0% 65kB ± 0% -56.44% (p=0.000 n=10+10) name old allocs/op new allocs/op delta PeerSetRemoveOne-8 85.0 ± 0% 73.0 ± 0% -14.12% (p=0.000 n=10+10) PeerSetRemoveMany-8 1.32k ± 0% 1.22k ± 0% -7.51% (p=0.000 n=10+10) ``` which savings become so much more when peers are removed much more frequently for a longer period of time and could mitigate DOS vectors. Fixes cometbft#2157 Fixes cometbft#2158
4319780 to
7854c3e
Compare
melekes
approved these changes
Jan 29, 2024
|
@odeke-em can you update the PR or allow core developers to update your fork so we can merge latest main into your branch? |
|
Closing in favor of #2246 |
github-merge-queue bot
pushed a commit
that referenced
this pull request
Feb 12, 2024
…rformance (#2246) Original PR: #2159 ## Breaking changes - `[p2p]` Rename `IPeerSet#List` to `Copy`, add `Random`, `ForEach` methods. Rename `PeerSet#List` to `Copy`, add `Random`, `ForEach` methods. Fixes #2158 ## Performance improvement This change makes PeerSet.Remove much more efficient simply by using more idiomatic Go re-slicing to avoid the prior mechanisms of creating fresh peer set lists on just a single remove. While here also added a remedy for a found bug #2158 due to an abstraction that returns a stale slice to its caller in Switch.OnStop. Benchmark results: ```shell $ benchstat before.txt after.txt name old time/op new time/op delta PeerSetRemoveOne-8 90.5µs ± 4% 95.9µs ±13% ~ (p=0.218 n=10+10) PeerSetRemoveMany-8 1.58ms ± 4% 1.50ms ± 1% -4.98% (p=0.000 n=10+8) name old alloc/op new alloc/op delta PeerSetRemoveOne-8 8.48kB ± 0% 7.92kB ± 0% -6.60% (p=0.000 n=10+10) PeerSetRemoveMany-8 149kB ± 0% 65kB ± 0% -56.44% (p=0.000 n=10+10) name old allocs/op new allocs/op delta PeerSetRemoveOne-8 85.0 ± 0% 73.0 ± 0% -14.12% (p=0.000 n=10+10) PeerSetRemoveMany-8 1.32k ± 0% 1.22k ± 0% -7.51% (p=0.000 n=10+10) ``` which savings become so much more when peers are removed much more frequently for a longer period of time and could mitigate DOS vectors. Fixes #2157 --------- Co-authored-by: Emmanuel T Odeke <emmanuel@orijtech.com> Co-authored-by: Sergio Mena <sergio@informal.systems>
mergify bot
pushed a commit
that referenced
this pull request
Feb 12, 2024
…rformance (#2246) Original PR: #2159 ## Breaking changes - `[p2p]` Rename `IPeerSet#List` to `Copy`, add `Random`, `ForEach` methods. Rename `PeerSet#List` to `Copy`, add `Random`, `ForEach` methods. Fixes #2158 ## Performance improvement This change makes PeerSet.Remove much more efficient simply by using more idiomatic Go re-slicing to avoid the prior mechanisms of creating fresh peer set lists on just a single remove. While here also added a remedy for a found bug #2158 due to an abstraction that returns a stale slice to its caller in Switch.OnStop. Benchmark results: ```shell $ benchstat before.txt after.txt name old time/op new time/op delta PeerSetRemoveOne-8 90.5µs ± 4% 95.9µs ±13% ~ (p=0.218 n=10+10) PeerSetRemoveMany-8 1.58ms ± 4% 1.50ms ± 1% -4.98% (p=0.000 n=10+8) name old alloc/op new alloc/op delta PeerSetRemoveOne-8 8.48kB ± 0% 7.92kB ± 0% -6.60% (p=0.000 n=10+10) PeerSetRemoveMany-8 149kB ± 0% 65kB ± 0% -56.44% (p=0.000 n=10+10) name old allocs/op new allocs/op delta PeerSetRemoveOne-8 85.0 ± 0% 73.0 ± 0% -14.12% (p=0.000 n=10+10) PeerSetRemoveMany-8 1.32k ± 0% 1.22k ± 0% -7.51% (p=0.000 n=10+10) ``` which savings become so much more when peers are removed much more frequently for a longer period of time and could mitigate DOS vectors. Fixes #2157 --------- Co-authored-by: Emmanuel T Odeke <emmanuel@orijtech.com> Co-authored-by: Sergio Mena <sergio@informal.systems> (cherry picked from commit e1ee71c)
mergify bot
pushed a commit
that referenced
this pull request
Feb 12, 2024
…rformance (#2246) Original PR: #2159 ## Breaking changes - `[p2p]` Rename `IPeerSet#List` to `Copy`, add `Random`, `ForEach` methods. Rename `PeerSet#List` to `Copy`, add `Random`, `ForEach` methods. Fixes #2158 ## Performance improvement This change makes PeerSet.Remove much more efficient simply by using more idiomatic Go re-slicing to avoid the prior mechanisms of creating fresh peer set lists on just a single remove. While here also added a remedy for a found bug #2158 due to an abstraction that returns a stale slice to its caller in Switch.OnStop. Benchmark results: ```shell $ benchstat before.txt after.txt name old time/op new time/op delta PeerSetRemoveOne-8 90.5µs ± 4% 95.9µs ±13% ~ (p=0.218 n=10+10) PeerSetRemoveMany-8 1.58ms ± 4% 1.50ms ± 1% -4.98% (p=0.000 n=10+8) name old alloc/op new alloc/op delta PeerSetRemoveOne-8 8.48kB ± 0% 7.92kB ± 0% -6.60% (p=0.000 n=10+10) PeerSetRemoveMany-8 149kB ± 0% 65kB ± 0% -56.44% (p=0.000 n=10+10) name old allocs/op new allocs/op delta PeerSetRemoveOne-8 85.0 ± 0% 73.0 ± 0% -14.12% (p=0.000 n=10+10) PeerSetRemoveMany-8 1.32k ± 0% 1.22k ± 0% -7.51% (p=0.000 n=10+10) ``` which savings become so much more when peers are removed much more frequently for a longer period of time and could mitigate DOS vectors. Fixes #2157 --------- Co-authored-by: Emmanuel T Odeke <emmanuel@orijtech.com> Co-authored-by: Sergio Mena <sergio@informal.systems> (cherry picked from commit e1ee71c)
mattac21
pushed a commit
that referenced
this pull request
Sep 5, 2025
…rformance (#2246) Original PR: #2159 - `[p2p]` Rename `IPeerSet#List` to `Copy`, add `Random`, `ForEach` methods. Rename `PeerSet#List` to `Copy`, add `Random`, `ForEach` methods. Fixes #2158 This change makes PeerSet.Remove much more efficient simply by using more idiomatic Go re-slicing to avoid the prior mechanisms of creating fresh peer set lists on just a single remove. While here also added a remedy for a found bug #2158 due to an abstraction that returns a stale slice to its caller in Switch.OnStop. Benchmark results: ```shell $ benchstat before.txt after.txt name old time/op new time/op delta PeerSetRemoveOne-8 90.5µs ± 4% 95.9µs ±13% ~ (p=0.218 n=10+10) PeerSetRemoveMany-8 1.58ms ± 4% 1.50ms ± 1% -4.98% (p=0.000 n=10+8) name old alloc/op new alloc/op delta PeerSetRemoveOne-8 8.48kB ± 0% 7.92kB ± 0% -6.60% (p=0.000 n=10+10) PeerSetRemoveMany-8 149kB ± 0% 65kB ± 0% -56.44% (p=0.000 n=10+10) name old allocs/op new allocs/op delta PeerSetRemoveOne-8 85.0 ± 0% 73.0 ± 0% -14.12% (p=0.000 n=10+10) PeerSetRemoveMany-8 1.32k ± 0% 1.22k ± 0% -7.51% (p=0.000 n=10+10) ``` which savings become so much more when peers are removed much more frequently for a longer period of time and could mitigate DOS vectors. Fixes #2157 --------- Co-authored-by: Emmanuel T Odeke <emmanuel@orijtech.com> Co-authored-by: Sergio Mena <sergio@informal.systems>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change makes PeerSet.Remove much more efficient simply by using more idiomatic Go re-slicing to avoid the prior mechanisms of creating fresh peer set lists on just a single remove. While here also added a remedy for a found bug #2158 due to an abstraction that returns a stale slice to its caller in Switch.OnStop.
Benchmark results:
$ benchstat before.txt after.txt name old time/op new time/op delta PeerSetRemoveOne-8 90.5µs ± 4% 95.9µs ±13% ~ (p=0.218 n=10+10) PeerSetRemoveMany-8 1.58ms ± 4% 1.50ms ± 1% -4.98% (p=0.000 n=10+8) name old alloc/op new alloc/op delta PeerSetRemoveOne-8 8.48kB ± 0% 7.92kB ± 0% -6.60% (p=0.000 n=10+10) PeerSetRemoveMany-8 149kB ± 0% 65kB ± 0% -56.44% (p=0.000 n=10+10) name old allocs/op new allocs/op delta PeerSetRemoveOne-8 85.0 ± 0% 73.0 ± 0% -14.12% (p=0.000 n=10+10) PeerSetRemoveMany-8 1.32k ± 0% 1.22k ± 0% -7.51% (p=0.000 n=10+10)which savings become so much more when peers are removed much more frequently for a longer period of time and could mitigate DOS vectors.
Fixes #2157
Fixes #2158