#36501 refactor : Reorder CBlockIndex members to save 8 bytes

ReviewabilityReviewsAgreementSize
#36501 bartoli refactor : Reorder CBlockIndex members to save 8 bytesReady2Strong5
  • Reduce memory footprint for every block known to the node by eliminating struct alignment padding
  • Saves roughly 8MB of resident RAM per one million blocks on 64-bit systems
  • Ready to review: no known blockers or pending changes
  • Strong substantive support with no open objections
  • Verified the struct size reduction on 64-bit platforms and confirmed safety (l0rinc)
  • Argued compiler checks and language rules prevent layout or initialization issues (maflcko)
  • Asked for clear proof and verification methods rather than assuming no side effects (stickies-v)
  • 5 lines added or modified outside tests
  • 0 lines added or modified in tests
  • 5 lines removed in total
  • 1 files, 1 commits
Validation#50 of 53
P4 · speedup
  • P4 because saving roughly 8MB of RAM across one million blocks is a marginal reduction on 64-bit nodes
  • It provides a harmless memory optimization but does not address primary validation bottlenecks
Ranking notes
Reviewability: ReadyStalePaused
Agreement: StrongPositivePositive w/ caveatsNeutralMildDisputedBlockedCrickets
Reviews: current code-review ACKs, then (+stale ACKs) and -NACKs; greener = more ACKs.
Size: lines added or modified outside tests, then in tests; greener = smaller.

Goal

Reorders member variables within CBlockIndex to group 4-byte fields together and eliminate 8 bytes of struct alignment padding on 64-bit platforms. Moving unsigned int nTx after uint64_t m_chain_tx_count aligns it next to the 4-byte nStatus field. This reduces the in-memory footprint of CBlockIndex by 8 bytes per instance across the entire block index.

Problem: Every block known to the node keeps a CBlockIndex object resident in memory. Member ordering currently places a 4-byte field between an arith_uint256 and an 8-byte uint64_t, wasting 8 bytes per object in compiler padding on 64-bit systems.

Evidence of importance:

  • Commit d9387c41c1 notes that on a Windows x64 build, CBlockIndex size decreases by 8 bytes (from 152 bytes), saving approximately 8MB of RAM for a chain of ~1M blocks.
  • Author description confirms in synthetic tests that inflating CBlockIndex size by 320 bytes increased RAM usage by ~300MB, confirming roughly one instance exists per block.

Risk of a mistake: low (validation). CBlockIndex is an in-memory tracking structure not directly serialized to disk, so reordering members does not break consensus, serialization, or network protocols.

Changed since the previous assessment: No changes; the commit and diff remain identical to the previous version.

Reviewability

Ready

Nothing known that would invalidate a review now.

Waiting on (from the thread read):

  • nothing: no pending items or requests

Agreement

Strong

substantive support, no open objection (l0rinc, maflcko)

Thread notes: Added maflcko's comment addressing safety considerations regarding serialization and C++20 aggregate initialization.

Objections, suggestions, and questions:

ReviewerTypeHarm, request, or questionStatusMust beAuthor repliedQuote
stickies-v (member)suggestion, safetyExhaustively explain why reordering CBlockIndex members is safe against memory layout dependencies and how reviewers can verify it, rather than asserting no side effectsanswered · author agreed more checks were needed and maflcko noted compiler protections against layout issuesansweredyes2026-10-13: 'the PR should let reviewers falsify its assumptions rather than assert "no side effects"'
Status from: 2026-10-13: bartoli: 'you are definately right about more needed checks on accesses inside the node process'

Support:

  • l0rinc (member) (ACK, 2026-10-11) [both: CBlockIndex]: verified 152 to 144 bytes reduction on 64-bit and sees no downside to the swap as fields initialize independently and serialization is unchanged
  • maflcko (member) (ACK, 2026-10-12): lgtm [not substantive]
  • maflcko (member) (2026-10-27) [read: CBlockIndex]: byte-level access or order-dependent serialization would be pre-existing bugs, and C++20 P1008 rejects aggregate initialization issues at compile time

Participants:

  • l0rinc (member, support, 1 statements 2026-10-11 to 2026-10-11): ACKed after confirming the struct size reduction on 64-bit and finding no downside
  • maflcko (member, support, 2 statements 2026-10-12 to 2026-10-27): ACKed and argued memory order and C++20 aggregate initialization rules make the reordering safe
  • stickies-v (member, neutral, 1 statements 2026-10-13 to 2026-10-13): verified safety using clang-query but urged author to justify safety rather than asserting no side effects

Files

0 lines under test/bench/ci.

  • src/chain.h +5/-5

Card

The short text the ranking pass compares across PRs.

This pull request reorders member variables in CBlockIndex to eliminate 8 bytes of struct padding on 64-bit architectures. Bitcoin Core holds an in-memory CBlockIndex instance for every block header known to the node, so each byte saved scales with total chain length. The author calculates this saves roughly 7 to 8 MB of resident memory across roughly one million blocks. No dependencies or side effects are noted since CBlockIndex is an in-memory struct not serialized directly.

Data

dossier JSON · extract JSON · model ledger, generated 2026-10-28T01:22, confidence high, input hash 3d9f08ad46c62235
thread read through 2026-10-27 (5 statements), head d9387c41c1
labels: none

Categories

Validation

P4 · speedup

Reordering struct members eliminates 8 bytes of padding per CBlockIndex, saving roughly 8MB of RAM for 1M blocks. While a straightforward and harmless memory optimization on 64-bit systems, the overall impact is marginal compared to primary validation bottlenecks.

Membership: Modifies CBlockIndex in src/chain.h, altering the in-memory footprint of the core block index structure.

Factors: security/stability 0, bug 0, performance 1, user value 0, leverage 0