-
Notifications
You must be signed in to change notification settings - Fork 376
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
Minor #3270 Followups #3349
Minor #3270 Followups #3349
Conversation
In aa2f6b4 we refactored `lightning-invoice` de/serialization to use the new version of `bech32`, also reducing some trivial unnecessary allocations when we did so. Here we drop a few additional allocations which came up in review.
In aa2f6b4 we refactored `lightning-invoice` de/serialization to use the new version of `bech32`, but ended up adding one unnecessary allocation in our offers logic, which we drop here.
...in `debug_assertions`.
In aa2f6b4 we refactored `lightning-invoice` de/serialization to use the new version of `bech32`, but in order to keep the public API the same we introduced one allocation we could have skipped. Instead, here, we replace the public `Utf8Error` with `FromUtf8Error` which contains the original data which failed conversion, removing an allocation in the process.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3349 +/- ##
==========================================
- Coverage 89.62% 89.59% -0.04%
==========================================
Files 127 127
Lines 103517 103519 +2
Branches 103517 103519 +2
==========================================
- Hits 92780 92750 -30
- Misses 8041 8062 +21
- Partials 2696 2707 +11 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
When we serialize from a byte array to bech32 in `lightning-invoice`, we can either copy the array itself into the iterator or hold a reference to the array and iterate through that. In aa2f6b4 we opted to copy the array into the iterator, which is fine for the current array sizes we're working with, but does result in additional memory on the stack if, in the future, we end up writing large arrays. Instead, here, we switch to using the slice serialization code when writing arrays, (very marginally) reducing code size and reducing stack usage.
093f9fb
to
5c1440a
Compare
No description provided.