optimization: Preallocate addresses in GetAddr based on nNodes

[l0rinc]

The upper bound ensures efficient memory usage based on the input constraints.

before:

|               ns/op |                op/s |    err% |     total | benchmark
|--------------------:|--------------------:|--------:|----------:|:----------
|           76,852.79 |           13,011.89 |    0.4% |      1.07 | `AddrManGetAddr`
|           76,598.21 |           13,055.14 |    0.2% |      1.07 | `AddrManGetAddr`
|           76,296.32 |           13,106.79 |    0.1% |      1.07 | `AddrManGetAddr`

after:

|               ns/op |                op/s |    err% |     total | benchmark
|--------------------:|--------------------:|--------:|----------:|:----------
|           65,966.97 |           15,159.10 |    0.3% |      1.07 | `AddrManGetAddr`
|           66,075.40 |           15,134.23 |    0.2% |      1.06 | `AddrManGetAddr`
|           66,306.34 |           15,081.51 |    0.3% |      1.06 | `AddrManGetAddr`

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	stickies-v, vasild

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

[brunoerg]

Perhaps It would be better to cherry-pick this change into #29578 since that touches it?

[l0rinc]

@brunoerg, feel free to do that, I'll close this if you cherry-pick it to the other PR (please provide before/after measurements)

[vasild]

ACK 278a1ee

Note that this may overshoot and allocate more space than is going to be needed. Less so with #29578.

[brunoerg]

@brunoerg, feel free to do that, I'll close this if you cherry-pick it to the other PR (please provide before/after measurements)

Done.

[l0rinc]

Thanks for the review @vasild, we've moved it over to the other PR

[l0rinc]

Reopening since #29578 was closed without merge

[stickies-v]

ACK 66082ca

I don't think this is a particularly impactful change but it's very small and straightforward to review.

[vasild]

ACK 66082ca

[fanquake]

I don't think this is a particularly impactful change but it's very small and straightforward to review.

I agree, and I think we are probably overdue for a review of what is in src/bench, and cleaning out benchmarks that aren't (very) meaningful. IIRC clang-tidy has a check for exactly this kind of change, so I think if any more were going to be made, they could be done using that.

[fanquake]

The clang-tidy check I was thinking of was https://clang.llvm.org/extra/clang-tidy/checks/performance/inefficient-vector-operation.html.