Parallel pathfinding and other things - #319
Merged
Merged
Conversation
…e sync The scorer is only ever accessed under the node's outer lock (both send_payment and track_payment run with it held), so a tokio mutex buys nothing. A read-write lock rather than a mutex because LDK splits its scorer traits along the same line. Pathfinding goes through ScoreLookUp, which only takes &self, while ScoreUpdate needs &mut self and is only used to feed payment results back in. Routes for one node can therefore be computed concurrently under a shared read guard. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Move pathfinding for each payment to a spawn_blocking task. Routes for different payments are then computed in parallel, under a shared read guard on the node's scorer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…..>> Every LightningNode method already takes &self, and every implementation is internally sync. The real backends keep their RPC clients behind a mutex, and SimNode guards its in-flight, network and scorer behing a mutex. The outer mutex therefore protected nothing. Drop the mutex and add Sync to the trait bound, which every implementation already satisfies. Nodes are now shared as Arc<dyn LightningNode> and their methods called directly. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
elnosh
force-pushed
the
parallel-pathfinding
branch
from
September 15, 2026 21:36
2e58c74 to
5f88c81
Compare
elnosh
force-pushed
the
parallel-pathfinding
branch
from
September 15, 2026 21:38
5f88c81 to
d3c2575
Compare
carlaKC
approved these changes
Sep 16, 2026
carlaKC
left a comment
carlaKC
left a comment
Contributor
There was a problem hiding this comment.
Nice clean up! Haven't looked deeply into the paused runtime workings but will take your/claude's word for it!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I was running with a simulated network of ~26k channels and it was very slow. From looking at perf results it seems majority of time is spent on pathfinding. Not that pathfinding is slow but in a network with ~26k channels and default simulation values (send multiplier), the simulation will generate a lot of payments making majority of time spent on pathfinding. The payment volume increases a lot because each node is set to send some multiplier of its capacity per certain period. With high channel count, this will spike the payment generation.
Some things done here:
current_threadruntime,spawn_blockingwill spawn additional threads for blocking operations. So use that to parallelize pathfinding.LightningNode.0.2. We were on0.0.123which was a bit old. Pathfinder is a bit faster since then so bumped that dep.And just reducing the multiplier to generate less payments helped.