-
Notifications
You must be signed in to change notification settings - Fork 959
Make Json rpc more efficient #8585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Make Json rpc more efficient #8585
Conversation
a460471
to
71e9f48
Compare
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]>
Signed-off-by: Rusty Russell <[email protected]>
It's a little overkill, but it's clear. Signed-off-by: Rusty Russell <[email protected]>
71e9f48
to
e5f6efb
Compare
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 |
ACK e5f6efb |
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 ;-) |
Unify all the places where we read JSONRPC, using membuf which is the most efficient way, which we didn't always use.
Changelog-None