Pratik Mankawde f5900b96e8 perf: Cap the number of threads TaggedCache::sweep() starts ...

sweep() started one thread per cache partition, and the partition count
defaults to the host's core count, so a sweep of one cache started one
thread per core. Several caches are swept per timer tick, so the churn
multiplied by the number of caches.

Cap the workers instead of the partitions. sweep() now starts
min(partitions, kMaxSweepThreads) of them, and worker w takes partitions
w, w + workerCount, w + 2 * workerCount and so on, which covers every
partition exactly once.

sweepHelper decided what one partition's sweep does and also wrapped it
in a std::thread. Split those: sweepPartition returns void and runs in
the calling thread, and sweep() alone owns thread creation. Both
overloads change the same way; the sweeping logic is untouched.

Fewer workers means the exclusive cache lock is held for longer, since
sweep() joins inside it. That trade is unmeasured.

Add gtest cases for the cap, and for eviction reaching every partition on
both the key/value and key-only caches.

2026-09-17 22:04:59 +01:00

..

xrpl

perf: Cap the number of threads TaggedCache::sweep() starts

2026-09-17 22:04:59 +01:00