Vec<T> Compact implementation causes storage bloat for fixed-size types #17750
Closed
AshinGau
started this conversation in
Technical discussions
Replies: 1 comment
-
I think this doesn't really matter w.r.t the checkpoint progress table because it doesn't have much data, so I don't think this is super critical to fix. This is also better for uints that are not reth/crates/storage/codecs/src/lib.rs Lines 464 to 478 in f6ffeac which calls to: reth/crates/storage/codecs/src/lib.rs Lines 417 to 437 in f6ffeac |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Problem Description
The current
Vec<T>
implementation of theCompact
trait incrates/storage/codecs/src/lib.rs
has a significant storage inefficiency for fixed-size types:Storage Bloat: The default
Vec<T>::to_compact
implementation stores a length prefix for each element, which doubles the storage requirement for fixed-size types likeu8
. This is particularly problematic whenVec<u8>
is used in database tables.Current Implementation Analysis
The
&[T]::to_compact
implementation:Impact Example
For
Vec<u8>
with 1000 elements:Real-World Impact
The
StageCheckpointProgresses
table usesVec<u8>
as its value type:While this table is relatively small, the pattern could be repeated in other tables, leading to significant storage waste.
Root Cause
The issue stems from the generic
Vec<T>
implementation assuming all typesT
have variable sizes. For fixed-size types likeu8
,u32
,B256
, etc., storing individual length prefixes is unnecessary and wasteful.Proposed Solution
Option 1: Type-Specific Specializations
Add specialized implementations for common fixed-size types:
Option 2: Trait-Based Approach
Create a trait to identify fixed-size types:
Implementation Plan
Vec<u8>
,Vec<u32>
Impact
Vec<u8>
, significant savings for other fixed-size typesBeta Was this translation helpful? Give feedback.
All reactions