addrman: bump peers.dat format version number #23382

Checking 70k addresses takes 0.032 sec. If changed to unordered_map then it takes 0.017 sec. While that is ~2x speedup, I think it is insignificant during Serialize() and not worth introducing and maintaining CNetAddr hasher.

<details> <summary>CNetAddrHash</summary>

class CNetAddrHash
{
public:
    size_t operator()(const CNetAddr& a) const noexcept
    {
        CSipHasher hasher(m_salt_k0, m_salt_k1);
        hasher.Write(a.m_net);
        hasher.Write(a.m_addr.data(), a.m_addr.size());
        return static_cast<size_t>(hasher.Finalize());
    }

private:
    const uint64_t m_salt_k0 = GetRand(std::numeric_limits<uint64_t>::max());
    const uint64_t m_salt_k1 = GetRand(std::numeric_limits<uint64_t>::max());
};

</details>

std::sort + std::adjacent_find may be faster than both.

Inserting the elements in std::set<CNetAddr> is essentially sorting them (by address only). Inserting N elements would be O(N*log(N)). Same as std::sort, except that the std::set variant could quit early if a duplicate is found.

The std::unordered_set variant is O(N) (time and memory).

@vasild Yes, but both set/unordered_set will require an allocation per element. I would expect that to outweigh the complexity difference for the sizes we're talking about.

I played with this out of curiosity. Speed is not so important in this case. But anyway:

The "sort + adjacent_find":

    std::vector<CNetAddr> dup_guard;
    dup_guard.reserve(mapAddr.size());
    for (const auto& [addr, id] : mapAddr) {
        dup_guard.push_back(addr);
    }
    std::sort(dup_guard.begin(), dup_guard.end());
    const bool duplicates_by_addr =
        std::adjacent_find(dup_guard.begin(), dup_guard.end()) != dup_guard.end();

Performs about the same as the unordered_set variant. The reserve() call is very important - if missing then this is slower than unordered_set.

However, the unordered_set also benefits from a reserve() call:

    std::unordered_set<CNetAddr, CNetAddrHash> dup_guard;
    dup_guard.reserve(mapAddr.size());

This makes it the fastest on Earth - 0.011 sec.

The above is for about 70k entries without duplicates (worst case). If there are duplicates, then the unordered_set is even faster as it would cancel the sorting somewhere in the middle (sorting is the slowest operation). In my case, with just 73 duplicates from 70k entries, the timings from a few runs are: 0.0013, 0.00077, 0.002, 0.00064.

Clang 13, -O2