pay: Speed up pay and fix the shadow route construction
#3617
Conversation
This file contains 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
|
As kids say these days, "LOL WUT?" Ack 79c05b0 |
|
Also deserves a Changelog-Fixed: line IMHO. |
|
Will add a changeling ASAP 👍 |
The shadow route algorithm is extending the route randomly using channels adjacent to the current destination, in the hope to create a plausible route extension. However, instead of only retrieving the channels adjacent to the destination it was retrieving all channels in the entire topology, and selecting a random channel from there. This resulted in a very large request for all channels being processed, and then mostly not being used, but also in shadow extensions to the path which were not plausible (they didn't extend the real path, just random edges). This is fixed by restricting the call to `listchannels` to the channels with the current destination as source. On my laptop retrieving all channels in the current mainnet takes approximately 1.2 seconds, and given the geometric series expansion of the 50% extension probability this indeed would result in an overhead of 1.2 seconds to the `pay` command. In contrast specifying a source results in an overhead of ~30ms. So good news everyone, your pay commands just shaved 1.17 seconds off their runtime. Changelog-Changed: pay: Improved the performance of the `pay`-plugin by limiting the `listchannels` when computing the shadow route. Changelog-Fixed: pay: The `pay`-plugin was generating non-contiguous shadow routes
|
Added two changelog entries: one for the speedup and one for the shadow route fix 😉 |
|
Ack 1202cb4 |
rustyrussell
approved these changes
Apr 4, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The shadow route algorithm is extending the route randomly using channels
adjacent to the current destination, in the hope to create a plausible route
extension. However, instead of only retrieving the channels adjacent to the
destination it was retrieving all channels in the entire topology, and
selecting a random channel from there. This resulted in a very large request
for all channels being processed, and then mostly not being used, but also in
shadow extensions to the path which were not plausible (they didn't extend the
real path, just random edges). This is fixed by restricting the call to
listchannelsto the channels with the current destination as source.On my laptop retrieving all channels in the current mainnet takes
approximately 1.2 seconds, and given the geometric series expansion of the 50%
extension probability this indeed would result in an overhead of 1.2 seconds
to the
paycommand. In contrast specifying a source results in an overheadof ~30ms.
So good news everyone, your pay commands just shaved 1.17 seconds off their
runtime.