Skip to content

perf(storage): optimize wiped storage entry collection to avoid unnecessary Vec allocation #19077

@yongkangc

Description

@yongkangc

Problem

There's a TODO comment at provider.rs:2279-2287 indicating that the collection of wiped storage entries could be rewritten more efficiently:

// TODO(mediocregopher): This could be rewritten in a way which doesn't require
// collecting wiped entries into a Vec like this, see
// `write_storage_trie_changesets`.
let mut wiped_storage = Vec::new();
if wiped {
    tracing::trace!(?address, "Wiping storage");
    if let Some((_, entry)) = storages_cursor.seek_exact(address)? {
        wiped_storage.push((entry.key, entry.value));
        while let Some(entry) = storages_cursor.next_dup_val()? {
            wiped_storage.push((entry.key, entry.value))
        }
    }
}

Currently, the code:

  1. Allocates a Vec to collect all wiped storage entries
  2. Iterates through the cursor and pushes each entry into the Vec
  3. This intermediate collection adds allocation overhead and an extra iteration

Proposed Optimization

Refactor to use the approach from write_storage_trie_changesets which likely:

  • Processes entries directly from the cursor without intermediate collection
  • Avoids unnecessary Vec allocations
  • Reduces memory pressure during block persistence

Context

This optimization is part of the broader static file write optimization effort (#19057) to reduce block persistence latency and ensure write throughput matches block production rates.

Metadata

Metadata

Assignees

Labels

A-dbRelated to the databaseC-perfA change motivated by improving speed, memory usage or disk footprintD-good-first-issueNice and easy! A great choice to get started

Type

No type

Projects

Status

Backlog

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions