Store Feature flags in line rather than on the heap by default (without increasing their size)
#3730
Conversation
|
I've assigned @valentinewallace as a reviewer! |
TheBlueMatt
force-pushed
the
2025-04-features-less-alloc
branch
4 times, most recently
from
61824a3 to
03aaa63
Compare
This avoids vec doubling while doing `Features` conversions.
TheBlueMatt
force-pushed
the
2025-04-features-less-alloc
branch
from
03aaa63 to
1160c31
Compare
In a running LDK instance we generally have a ton of `Feature`s objects flying around, including ones per channel/peer in the `NetworkGraph`, ones per channel/peer in `Channel`/`ChannelManager`, and ones inside of BOLT 11/12 Invoices. Thus, its useful to avoid unecessary allocations in them to reduce heap fragmentation. Luckily, Features generally don't have more than 15 bytes worth of flags, and because `Vec` has a `NonNull` pointer we can actually wrap a vec in a two-variant enum with zero additional space penalty. While this patch leaves actually deserializing `Features` without allocating as a future exercise, immediately releasing the allocation is much better than holding it, and `Features` constructed through repeated `set_*` calls benefit from avoiding the Vec entirely.
TheBlueMatt
force-pushed
the
2025-04-features-less-alloc
branch
from
1160c31 to
2dd6c18
Compare
| #[derive(Clone, PartialEq, Eq)] | ||
| #[doc(hidden)] | ||
| pub enum FeatureFlags { | ||
| Held { bytes: [u8; DIRECT_ALLOC_BYTES], len: u8 }, |
There was a problem hiding this comment.
Should these be called OnStack/OnHeap or similar?
There was a problem hiding this comment.
But its not necessarily on stack - its just in the object, and the object may be on heap or on stack.
There was a problem hiding this comment.
Mhh. Good point, I just found the current naming a bit odd.
There was a problem hiding this comment.
Maybe Heap and Direct? I agree its odd but I don't know what's better.
|
🔔 1st Reminder Hey @valentinewallace! This PR has been waiting for your review. |
lightning-types/src/features.rs
Outdated
| // Thus, as long as we never use more than 15 bytes for our Held variant `FeatureFlags` is the same | ||
| // length as a `Vec` in memory. |
There was a problem hiding this comment.
Is it not 16 bytes (2 usizes as mentioned above) because we need a byte to write the type of features, or? Would be helpful to clarify that.
There was a problem hiding this comment.
Right, 16 bytes minus the length byte, I'll clarify.
No new datastructure would be complete without a dedicated fuzzer, so we add one here.
TheBlueMatt
force-pushed
the
2025-04-features-less-alloc
branch
from
2dd6c18 to
fadb54f
Compare
In a running LDK instance we generally have a ton of
Features objects flying around, including ones per channel/peer in theNetworkGraph, ones per channel/peer inChannel/ChannelManager, and ones inside of BOLT 11/12 Invoices.Thus, its useful to avoid unecessary allocations in them to reduce heap fragmentation.
Luckily, Features generally don't have more than 15 bytes worth of flags, and because
Vechas aNonNullpointer we can actually wrap a vec in a two-variant enum with zero additional space penalty.While this patch leaves actually deserializing
Featureswithout allocating as a future exercise, immediately releasing the allocation is much better than holding it, andFeaturesconstructed through repeatedset_*calls benefit from avoiding the Vec entirely.