Fix O(n^2) algorithm in the GC cleanup logic

[JohnSully]

Because deletion from a vector is a linear operation the loop inside endEpoch() is O(n^2). It was written this way to be safe while deleting the vector but can cause serious consequences during large GC epochs where large numbers of epochs need to be cleared.

The fix is to move to a list datastructure with O(1) deletion. This is the more appropriate datastructure for this operation.

[VivekSainiEQ]

Would it be possible to use an unordered set? You could still iterate in O(N) and insert/delete in O(1), but this find operation would be O(1) instead of O(N)?

[JohnSully]

We rely on sorted order though

[VivekSainiEQ]

What about an ordered set? insertion/deletion would be logarithmic instead of constant, but so would this find.

[JohnSully]

Deletion is O(log n) though, this would regress us to O(n log n) performance instead of the O(n) that we are currently so its not a net benefit.

[paulmchen]

I verified this fix on my cloud environment. It is now much better, The '0 qps' issue cannot be reproduced during the fullsync replication cycle. Thanks John.

btw. the following changes will also help on minimizing the CPU usage during the GC cycle, i suggest we add the change to KEYDB core as well:

(gc.h)

class GarbageCollector
{
struct EpochHolder
{
uint64_t tstamp;
std::unique_ptr<std::vector<std::unique_ptr>> m_spvecObjs;

    EpochHolder() {
        m_spvecObjs = std::make_unique<std::vector<std::unique_ptr<T>>>();
    }

    // Support move operators
    EpochHolder(EpochHolder &&other) = default;
    EpochHolder &operator=(EpochHolder &&) = default;