Skip to content

Conversation

rustyrussell
Copy link
Contributor

@rustyrussell rustyrussell commented Oct 7, 2025

Unify all the places where we read JSONRPC, using membuf which is the most efficient way, which we didn't always use.

Changelog-None

@rustyrussell rustyrussell added this to the v25.12 milestone Oct 7, 2025
@rustyrussell rustyrussell force-pushed the json-rpc-more-efficient branch from a460471 to 71e9f48 Compare October 13, 2025 07:45
Without this they get run together on stderr.

Signed-off-by: Rusty Russell <[email protected]>
We have to call it membuf_tal_resize() because the other on is
a ccan/json_out static function!

Signed-off-by: Rusty Russell <[email protected]>
We do this in several places, might as well make it common code.

Signed-off-by: Rusty Russell <[email protected]>
…-pay.

They were never referenced, and saving the toks is questionable since their
lifetime is not guaranteed to live beyond this call (at least the buffer was
duplicated, but that also assumed it was at the start of the object).

Signed-off-by: Rusty Russell <[email protected]>
The efficient way to do this is to use membuf, which handles the buffer
control (only using memmove when necessary).  We have multiple places
where we opencoded this, some of which did not use membuf at all.

So now we create common infrastructure.  I tried making it a single
function but the various users are quite different, so instead I opted
for a toolbox approach.

Signed-off-by: Rusty Russell <[email protected]>
This will also be more efficient than doing memmove every time.

Signed-off-by: Rusty Russell <[email protected]>
Hand it in as a parameter to reduce churn in next patch.

Signed-off-by: Rusty Russell <[email protected]>
This is also more efficient if there are many commands at once.

Signed-off-by: Rusty Russell <[email protected]>
Hand it in as a parameter to reduce churn in the next patch.

Signed-off-by: Rusty Russell <[email protected]>
This is more efficient if we have lots of incoming commands, too.

Signed-off-by: Rusty Russell <[email protected]>
This is a trick from bcli: we ask bitcoind for the block, and it hands
us a 2MB hex blob (which we read in multiple parts).  Our parser wades
through it all, but a quick search for '}' makes it much faster.

Signed-off-by: Rusty Russell <[email protected]>
…se_handle off plugin->buffer.

Hand buffer in as a parameter to reduce churn in the next patch.

Signed-off-by: Rusty Russell <[email protected]>
It's a little overkill, but it's clear.

Signed-off-by: Rusty Russell <[email protected]>
@rustyrussell rustyrussell force-pushed the json-rpc-more-efficient branch from 71e9f48 to e5f6efb Compare October 20, 2025 05:36
@cdecker
Copy link
Member

cdecker commented Oct 20, 2025

Very nice PR, and excellent consolidation. I think you may have also addressed one of the major Greenlight issues, with that reparse fix of Blocks. We were spending an inordinate amount of CPU cycles on the JSON parsing and hex decoding, which I think you just side-stepped, with the sanity check of seeing if there is a } in the buffer. It kind of assumes there is no other } than the payload closing tag, but unless we start adding telemetry before the payload, we should be good with this. The alternative would be to keep a running tally of opens vs closes, that could also work.

@cdecker
Copy link
Member

cdecker commented Oct 20, 2025

ACK e5f6efb

@cdecker
Copy link
Member

cdecker commented Oct 20, 2025

There is just one issue: you seem to be reading past the end of the membuf, it looks like an off-by-one error to me ;-)

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