Files
bitcoin/src
W. J. van der Laan 7f7bd3111c Merge bitcoin/bitcoin#22974: addrman: Improve performance of Good
57ce20307e fuzz: allow lower number of sources (Martin Zumsande)
acf656d540 fuzz: Use public interface to fill addrman tried tables (Martin Zumsande)
eb2e113df1 addrman: Improve performance of Good (Martin Zumsande)

Pull request description:

  Currently, `CAddrman::Good()` is rather slow because the process of moving an addr from new to tried involves looping over the new tables twice:
  1) In `Good_()`, there is a loop searching for a new bucket the addr is currently in, but this information is never used except for aborting if it is not found anywhere (since [this commit](e6b343d880 (diff-49d1faa58beca1ee1509a247e0331bb91f8604e30a483a7b2dea813e6cea02e2R263)) it is no longer passed to `MakeTried`)
  This is unnecessary because in a non-corrupted addrman, an address that is not in New must be either in Tried or not at all in addrman, both cases in which we'd return early in `Good_()` and never get to this point.
  I removed this loop (and left a check for `nRefCount` as a belt-and-suspenders check).

  2) In `MakeTried()`, which is called from `Good_()`, another loop removes all instances of this address from new. This can be spedup by stopping the search at  `nRefCount==0`. Further reductions in `nRefCount` would only lead to an assert anyway.
  Moreover, the search can be started at the bucket determined by the source of the addr for which `Good` was called, so that if it is present just once in New, no further buckets need to be checked.

  While calls to `Good()` are not that frequent normally, the performance gain is clearly seen in the fuzz target `addman_serdeser`, where, because of the slowness in creating a decently filled addrman, a shortcut was created that would directly populate the tried tables by reaching into addrman's internals, bypassing `Good()` (#21129).
  I removed this workaround in the second commit: Using `Good()` is still slower by a factor of 2 (down from a factor of ~60 before), but I think that this compensated by the advantages of not having to reach into the internal structures of addrman  (see https://github.com/jnewbery/bitcoin/pull/18#issuecomment-775218676).

  [Edit]: For benchmark results see https://github.com/bitcoin/bitcoin/pull/22974#issuecomment-919435266 and https://github.com/bitcoin/bitcoin/pull/22974#issuecomment-920445700 - the benchmark `AddrManGood` shows a significant speedup by a factor >100.

ACKs for top commit:
  naumenkogs:
    ACK 57ce20307e
  jnewbery:
    ACK 57ce20307e
  laanwj:
    Code review ACK 57ce20307e
  theStack:
    ACK 57ce20307e
  vasild:
    ACK 57ce20307e

Tree-SHA512: fb6dfc198f2e28bdbb41cef9709828f22d83b4be0e640a3155ca42e771b6f58466de1468f54d773e794f780a79113f9f7d522032e87fdd75bdc4d99330445198
2021-09-20 19:47:55 +02:00
..
2021-09-10 11:18:58 +08:00
2020-12-08 19:26:30 +01:00
2021-08-20 16:59:41 +02:00
2021-09-15 22:22:10 -04:00
2020-11-19 15:48:24 +01:00
2021-09-11 10:47:02 +03:00
2021-06-20 16:56:07 +02:00
2021-07-30 11:21:51 +02:00
2021-07-30 11:21:51 +02:00
2020-12-31 09:45:41 +01:00
2021-03-17 17:59:22 -07:00
2021-03-17 17:59:22 -07:00
2020-12-31 09:45:41 +01:00
2021-06-03 13:53:31 +02:00
2021-09-16 21:16:39 +09:00
2021-01-07 18:07:09 +02:00
2021-01-04 12:31:31 +08:00
2021-09-11 10:47:02 +03:00
2021-04-06 14:50:17 +08:00
2020-12-31 09:45:41 +01:00
2020-12-31 09:45:41 +01:00
2021-08-23 21:38:34 -04:00
2020-04-30 09:19:14 -04:00
2021-08-20 16:59:41 +02:00
2021-08-20 16:59:41 +02:00
2020-10-12 12:14:53 -07:00
2020-04-16 13:33:09 -04:00