Make MonitorUpdatingPersister change persist type based on size

[TheBlueMatt]

One thing that smaller LDK clients might want is to use MonitorUpdatingPersister in many cases, but not if the ChannelMonitor is only, say, a few KiB when serialized. This avoids the overhead of compaction later if the actual monitor being persisted is tiny anyway.

I think this should be quite easy to do so tagging as a good first issue.

[0xZaddyy]

can i work on this sir?

[TheBlueMatt]

Sure!

[joostjager]

This avoids the overhead of compaction later if the actual monitor being persisted is tiny anyway.

Is this significant if the channel monitor is small anyway?

[TheBlueMatt]

If the storage layer is remote and high latency I think it could be? I guess in theory if we're really careful about the lookup logic (and the KVStore is async) we could do the loading in parallel (though its still a few more requests) but we'd still have to wait on compaction (without a background-compaction task running, which would require a generic spawn method...). Seems much easier to just check the length and skip some code for the common case :)

[joostjager]

If I understand it correctly, this is special casing for channels at the beginning of their life and when they grow, the node will switch over to persisting updates and compaction anyway?

To me it isn't quite clear if this is really worth it. If the hit is significant, it is also a problem when the channel has outgrown the 'small' stage anyway?

[TheBlueMatt]

If I understand it correctly, this is special casing for channels at the beginning of their life and when they grow, the node will switch over to persisting updates and compaction anyway?

Yes.

To me it isn't quite clear if this is really worth it. If the hit is significant, it is also a problem when the channel has outgrown the 'small' stage anyway?

Its more a recognition of two very different cases - if you're running an "edge node" that is just a wallet making occasional payments, then you're likely to never hit the "large" stage, and thus avoiding the compaction overhead is a really nice optimization. If you're a larger node that is forwarding/processing many payments, you're very likely to hit the "large" stage and the compaction penalty is worth it to avoid the writes.

[joostjager]

At what size would the "large" stage be entered then typically and how many htlcs/channel updates is that? A channel monitor of a few kb, that doesn't sound like all that many updates?

[TheBlueMatt]

Yea, dunno, we'd have to figure that out. I imagine most mobile nodes probably make in the 100s to low 1000s of payments in their entire lifetime, probably fewer on a single channel once you consider splicing and the like. 10KiB or whatever should be plenty for 100 or 250 payments.