Skip to content

Conversation

@tnull
Copy link
Contributor

@tnull tnull commented Jan 12, 2026

Previously, we'd always pre-allocate a lot of memory in NetworkGraph::new. While this can be a nice efficiency improvements to avoid unnecessary re-allocations, it can also result in unnecessarily allocating memory. Here, we add a new constructor that allows specifying the node and channel count estimates for pre-allocation.

Apart from that, we also update the numbers for Jan 2026, and now determine the pre-allocation factors dynamically based on the actual numbers when reading a persisted graph.

tnull added 3 commits January 12, 2026 09:44
Previously, we'd always pre-allocate a lot of memory in
`NetworkGraph::new`. While this can be a nice efficiency improvements to
avoid unnecessary re-allocations, it can also result in unnecessarily
allocating memory. Here, we add a new constructor that allows specifying
the node and channel count estimates for pre-allocation.
…eading

When reading a persisted network graph, we previously pre-allocated our
default node/channels estimate count for the respective `IndexedMap`
capacities. However, this might unnecessarily allocate memory on
reading, for example if we have an (almost) empty network graph for one
reason or another. As we have the actual counts of persisted nodes and
channels available, we here simply opt to allocate these numbers (plus
15%). This will also ensure that our pre-allocations will keep
up-to-date over time as the network grows or shrinks.
@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Jan 12, 2026

👋 I see @wpaulino was un-assigned.
If you'd like another reviewer assignment, please click here.

@codecov
Copy link

codecov bot commented Jan 12, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.60%. Comparing base (c722443) to head (a6a70dc).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4306      +/-   ##
==========================================
+ Coverage   86.59%   86.60%   +0.01%     
==========================================
  Files         158      158              
  Lines      102408   102417       +9     
  Branches   102408   102417       +9     
==========================================
+ Hits        88678    88697      +19     
+ Misses      11309    11303       -6     
+ Partials     2421     2417       -4     
Flag Coverage Δ
fuzzing 35.88% <69.23%> (-1.00%) ⬇️
tests 85.89% <100.00%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

///
/// To improve efficiency, this will pre-allocate memory for `node_count_estimate` nodes and
/// `channel_count_estimate` channels.
pub fn from_node_and_channel_count_estimates(
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm pretty skeptical of exposing this. If you don't want a network graph, don't build one. If you want a network graph, we should allocate for a network graph. How is a downstream dev better positioned to provide estimates here than we are?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, from my point of view it is a bit odd to pre-allocate a lot of memory based on static estimations that will become stale over time. Plus, we currently make no distinction based on Network here, so we will always allocate that much memory even for small Regtest or Signet environments with only a hand full of nodes (e.g., in tests). If you're skeptical, maybe we can drop the extra constructor, but leave the dynamic allocation on read, and only apply the estimates for Network::Bitcoin?

Of course, I have to admit that I first had planned to use that constructor for the minimal-mode Node over at LDK Node, but you're right, for that application we probably need to completely change up our types there and simply rip out anything related to the Router/NetworkGraph entirely.

@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@tnull tnull requested a review from TheBlueMatt January 14, 2026 11:19
@TheBlueMatt TheBlueMatt removed the request for review from wpaulino January 14, 2026 12:27
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.

3 participants