Part of #30289.
This adds a few optimizations to reduce TxGraph’s memory usage, and makes sure that dynamic memory it uses doesn’t linger after shrinking clusters. Finally, it exposes a function GetMainMemoryUsage() to compute TxGraph’s approximate memory usage.
On my 64-bit system, it needs 72 bytes per transaction, 120 bytes per cluster, and 64 bytes per chunk. The code using it also needs a TxGraph::Ref object per transaction, at 16 bytes per transaction. Overall, this means up to 272 bytes per transaction. Experimenting with this integrated into #28676 shows a total per-transaction overhead of ~720 bytes per mempool transaction, while master has around ~548 bytes per transaction. Or expressed as a ratio of memory usage divided by mempool vsize, 5.8 in master and 6.4 in cluster mempool.
When designing TxGraph, the intent was to make the Cluster type a virtual class, with different instances for different cluster sizes (in particular, for singletons) that could optimize memory usage in a more tailored way. I have a very immature idea about getting rid of DepGraph instances inside Cluster after #32545, which would cut the increase in overhead down, so I’m not including that here.
Another memory usage optimization that may worthwhile, independently of the idea above, is to special-case singleton clusters (given the large fraction of transactions those are) and just store those as a list of transactions rather than having individual Cluster objects for them. I’m estimating that could save ~96 bytes per singleton-cluster transaction, but I’m leaving that for a potential future improvement too.
