Skip to content

feat: Make MonitorUpdatingPersister change persist type based on size #3834

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Prabhat1308
Copy link
Contributor

fixes #3770

  • Skips full persistence when ChannelMonitor is smaller than a pre-determined size.
  • Adds a field minimum_monitor_size_for_updates to specify the minimum size for full persistence to be activated
  • Adds new_with_default_threshold function to setup MonitorUpdatingPersister with a default minimum_monitor_size_for_updates value

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jun 7, 2025

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@tnull tnull requested review from tnull and removed request for joostjager June 9, 2025 07:24
/// For small channel monitors (below `minimum_monitor_size_for_updates` bytes when serialized),
/// this persister will always write the full monitor instead of individual updates. This avoids
/// the overhead of managing update files and later compaction for tiny monitors that don't benefit
/// from differential updates.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is still not clear to me how much the gain is of this in practice. Also worried that disabling the incremental path initially allow certain bugs to linger for longer, just because the path isn't hit as much, or rarely.

Copy link
Contributor

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks good, but can we add some test coverage for the new behavior?

Additionally, benchmarks would indeed very helpful to evaluate what a reasonable threshold value would be.

@@ -458,6 +465,7 @@ where
kv_store: K,
logger: L,
maximum_pending_updates: u64,
minimum_monitor_size_for_updates: usize,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please specify the unit of size in the variable name if possible.

/// in full rather than using update-based persistence.
///
/// For other parameters, see [`MonitorUpdatingPersister::new`].
pub fn new_with_default_threshold(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, should we rather leave new the one applying the default threshold and rather add a new_with_monitor_size_threshold or similar constructor?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make MonitorUpdatingPersister change persist type based on size
4 participants