docs(trie): fix doc drift after anchor_hash simplification
Update documentation to reflect that anchor_hash is metadata only
and does not affect overlay reuse decisions.
6a60626
2 days ago
by yongkangc
+0.2%
test(trie): add multi-ancestor overlay reuse test for anchor change
Adds test that verifies a chain of 3 blocks with old anchor correctly
reuses the cumulative overlay when a 4th block is added with a new
anchor (simulating post-persist scenario).
efb9725
1 day ago
by yongkangc
-0.13%
cp,,emts
7889faf
1 day ago
by yongkangc
-0.11%
update
644f156
1 day ago
by yongkangc
+0.09%
perf(trie): use deep copy for overlay reuse to avoid Arc::make_mut clone
Replace Arc::clone with explicit deep copy (Arc::new + clone) when reusing
parent's overlay. This ensures strong_count = 1, so Arc::make_mut in the
extend step is a no-op instead of triggering a full overlay clone.
Before: Arc::clone created shared ownership (strong_count = 2), causing
Arc::make_mut to clone the entire overlay - effectively doubling the work.
After: Deep copy upfront means Arc::make_mut sees strong_count = 1 and
returns &mut directly without cloning.
This also fixes memory retention with delayed persistence (500ms wait):
deep copy breaks the Arc chain so each overlay has independent lifetime.
85c7373
1 day ago
by yongkangc
-0.01%
cleanup comment
5cb709f
1 day ago
by yongkangc
+0.02%
fix(trie): clarify overlay reuse logic based on anchor_hash
Updated comments and tests to reflect that the overlay data is dependent on the anchor_hash. The overlay can only be reused if it was built on the same anchor; otherwise, it must be rebuilt from ancestors. This change ensures correct state application and improves understanding of the overlay reuse mechanism.
8a2eb30
1 day ago
by yongkangc
-0.04%
feat: pre-compute trie overlay at persist time with non-blocking rebuild
After persistence, the anchor hash changes and the cached overlay cannot be
reused. Previously, the first block after persist paid O(N) rebuild cost on
the critical validation path, causing p99 latency spikes.
This change spawns a background task after persist completes that:
1. Collects all remaining in-memory blocks
2. Builds a cumulative overlay from their already-computed trie data
3. Updates the tip block's cached overlay with the new anchor
Key design decisions:
- Uses non-blocking try_get()/try_trie_data() to avoid competing with block
validation - if any trie data is still pending, the task bails out early
- The next block validation will trigger synchronous rebuild as fallback
- Since persist runs every ~500ms and blocks arrive every ~12s, the background
task almost always succeeds before the next block needs the overlay
New APIs:
- DeferredTrieData::try_get() - returns None if pending (never computes)
- DeferredTrieData::update_cached_overlay() - updates anchor and overlay in-place
- ExecutedBlock::try_trie_data() - non-blocking wrapper around try_get()