You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@paulhauner observed that we could save space in memory by storing the values of packed leaves inside the Hash256. There's no hashing of packed leaves, and they always fit within 32 bytes, so in theory there's no need to duplicate them in memory as we do currently:
The easiest approach is probably to retain the Has256 and read the smaller sized integers off it on-demand, but we could also take the opposite approach: store the integers and compute the Hash256 on-demand. This latter option may be preferable as the Hash256should only be read once, when hashing the parent, whereas the values may be read numerous times. On the other hand, the Hash256 is allocated in-line rather than on the heap, so is probably more memory-efficient, and quicker to perform copy-on-write updates on.
The text was updated successfully, but these errors were encountered:
@paulhauner observed that we could save space in memory by storing the values of packed leaves inside the
Hash256
. There's no hashing of packed leaves, and they always fit within 32 bytes, so in theory there's no need to duplicate them in memory as we do currently:milhouse/src/packed_leaf.rs
Lines 8 to 15 in 4035d25
The easiest approach is probably to retain the
Has256
and read the smaller sized integers off it on-demand, but we could also take the opposite approach: store the integers and compute theHash256
on-demand. This latter option may be preferable as theHash256
should only be read once, when hashing the parent, whereas the values may be read numerous times. On the other hand, theHash256
is allocated in-line rather than on the heap, so is probably more memory-efficient, and quicker to perform copy-on-write updates on.The text was updated successfully, but these errors were encountered: