Skip to content

perf(storer): filter reserve chunks by proximity before unmarshaling in sampler - #5616

Open
gacevicljubisa wants to merge 2 commits into
masterfrom
perf/sample-early-proximity-filter
Open

gacevicljubisa wants to merge 2 commits into
masterfrom
perf/sample-early-proximity-filter

Conversation

@gacevicljubisa

Copy link
Copy Markdown
Member

Checklist

  • I have read the coding guide.
  • My change requires a documentation update, and I have done it.
  • I have added tests to cover my changes.
  • I have filled out the description and linked the related issues.

Description

This PR introduces an early proximity filter for the reserve chunk iterator during ReserveSample:

  • Direct DB value inspection without unmarshaling: Because ChunkBinItem serializes the chunk address at a fixed offset (byte 9, right after the 1-byte bin and 8-byte bin ID), reserve.ProximityFilter extracts the 32-byte chunk address directly from the raw LevelDB value buffer.
  • Skipping rejected entries at the iterator boundary: If a chunk's proximity to the anchor is < committedDepth, the iterator skips it immediately. This completely avoids allocating a value copy, instantiating &reserve.ChunkBinItem{}, and unmarshaling all fields (Address, BatchID, StampHash, etc.) for non-matching chunks.
  • Where the real benefits apply: On nodes with capacity doubling enabled (committedDepth > storageRadius), the reserve contains chunks in bins $\ge \text{storageRadius}$ that do not satisfy the required committedDepth for the sample round. For these nodes, this eliminates large amounts of heap allocations and unmarshaling work during sampling.

Open API Spec Version Changes (if applicable)

N/A

Motivation and Context (Optional)

Part of reserve sampling performance optimizations.

Related Issue (Optional)

#5174

Screenshots (if appropriate):

AI Disclosure

  • This PR contains code that has been generated by an LLM.
  • I have reviewed the AI generated code thoroughly.
  • I possess the technical expertise to responsibly review the code generated in this PR.

gacevicljubisa and others added 2 commits September 14, 2026 11:57
Sampling is about to start reading chunks into a buffer that each worker
reuses. Nothing today checks that the bytes handed back in a SampleItem are
still the bytes of that chunk, so a reused buffer would silently hand the
redistribution proof the contents of some later chunk.

assertValidSample now checks two things for every item: that ChunkData still
reproduces ChunkAddress, and that no two items share a backing array. Every
existing sample test picks both up.

Also add the rulers for the work that follows. BenchmarkReserveSample1k keeps
its name and behaviour so the recorded baseline stays comparable; its body
moves to a helper that BenchmarkReserveSample10k reuses over a ten times
larger reserve. BenchmarkChunkStoreGet measures a single chunk read, split
into a variant that builds the ChunkStore handle per call as the sampler does
today and one that hoists it, so the cost of the handle alone is visible.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KFUseFQ8rhp6N9X6YS7pbq

@aloknerurkar aloknerurkar left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants