Do not fully sort all nodes for addr relay#8690
Conversation
sipa
changed the title
|
I had an alternative version that used a heap (which needs less iterator arithmetic), but realized that just explicitly keeping track of the top two is faster (and doesn't need any allocations). |
|
@sipa is it worth benchmarking this (since you mentioned benchmarking)? |
|
@rebroad Perhaps, but that will need abstracting this code out so it can be tested in separation from the rest of the p2p message handing. |
src/main.cpp
Outdated
There was a problem hiding this comment.
There should be an assert here that nRelayNodes is <=2, no?
sipa
force-pushed
the
heapaddrsort
branch
3 times, most recently
from
076d877 to
12df591
Compare
|
Rebased and addressed @gmaxwell's nit. |
|
utACK. |
As we only need 1 or 2, explicitly keep track of the best ones.
|
Rebased after #8914. |
Yes if you just need the top two, a heap is overkill. Even if this doesn't speed up the critical path this conceptually makes a lot of sense. utACK a33b169 |
a33b169 Do not fully sort all nodes for addr relay (Pieter Wuille)
a33b169 Do not fully sort all nodes for addr relay (Pieter Wuille)
a33b169 Do not fully sort all nodes for addr relay (Pieter Wuille)
a33b169 Do not fully sort all nodes for addr relay (Pieter Wuille)
4 participants
This is a small optimization, but I have not benchmarked.
Instead of building a hash->node map for each address being relayed, and then picking the top ones, just compute the top 1-2 ones directly.