Skip to content

Askrene: scale with many layers#8760

Merged
rustyrussell merged 3 commits intoElementsProject:masterfrom
rustyrussell:askrene-many-layers
Jan 27, 2026
Merged

Askrene: scale with many layers#8760
rustyrussell merged 3 commits intoElementsProject:masterfrom
rustyrussell:askrene-many-layers

Conversation

@rustyrussell
Copy link
Contributor

@Lagrang3 pointed out that our single linked list of layers will become a bottleneck, so this contains a quick benchmark for many layers, and replaces the linked list with a hashtable.

Changelog-None

@rustyrussell rustyrussell added this to the v26.03 milestone Dec 5, 2025
@Lagrang3
Copy link
Collaborator

Lagrang3 commented Jan 6, 2026

Nice.
On the results of the benchmark I just want to point out that this is only measuring the time it takes to create X many layers.
For a linked list adding a new element takes O(1) as well as for the hashtable with no doubt also a higher cost due to
the hashing (and possibly string comparisons in case of collisions?).
It surprises me the amount of time: like 1 minute for just 100k layers!?
My guess is that most of time is spent in IO being plain text and involving pyln -> lightningd-> askrene and back.

I would like to see a benchmark to measure the time we spend fetching layers.

UPD: I've noticed that the linked list of layers is worse than the hashtable adding elements because askrene checks if the layer exists before creating a new one, making askrene-create-layer behave like O(N). So the benchmark on the linked list version will take forever on 100'000 askrene-create-layer queries.

This means it has to do a lookup and an insert.

Signed-off-by: Rusty Russell <[email protected]>
Simple bench.

Before:
   Creating 20,000 layers:  20 seconds
   Creating 50,000 layers:  107 seconds

After:
   Creating 20,000 layers:  7 seconds
   Creating 50,000 layers:  15 seconds
   Creating 100,000 layers: 29 seconds

Signed-off-by: Rusty Russell <[email protected]>
…ers on startup.

We used non-persistent layers before, but what if we save to the datastore and restore?

This takes it from 29 to 45 seconds.

Signed-off-by: Rusty Russell <[email protected]>
@rustyrussell
Copy link
Contributor Author

It surprises me the amount of time: like 1 minute for just 100k layers!?

I re-ran with a rebase: it's halved. Technically we could send all the commands at once rather than waiting for the responses, but when I do that with futures in Python, the pytest starts dominating the CPU and the result is actually slower :(

@rustyrussell rustyrussell merged commit c7d313e into ElementsProject:master Jan 27, 2026
43 checks passed
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.

2 participants