execution/commitment: enchance MPT hashing hot-paths to reduce allocations

[Sahil-4555]

This PR includes targeted memory improvements to the execution/commitment MPT hashing hot-paths, resulting in considerable reductions in total allocation and execution time. The improvements are achieved by gradually replacing dynamic heap allocations with pre-allocated structural buffers. We specifically developed a zero-allocation HexToCompactBuf method and added [128]byte scratch buffers to the HexPatriciaHashed object to entirely minimize memory escapes while encoding keys during branch folding and unfolding. Furthermore, we avoided costly per-job make([]byte) allocations by embedding a [64]byte prefix array directly into the pooled DeferredBranchUpdate struct, ensuring thread-local data separation for concurrent workers.

we optimized the cell.fillFromFields deserializer's extraction logic is inlined to eliminate closure and slice-of-structs overhead. Finally, we eliminated unnecessary array-clearing processes in cell.reset() (using existing length-gated reads instead) and changed computeCellHash to use stack-allocated buffers for prepending state hashes.

goos: linux
goarch: amd64
pkg: github.com/erigontech/erigon/execution/commitment
cpu: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz
                            │ baseline_opt_2.txt │         optimize_opt_2.txt          │
                            │       sec/op       │   sec/op     vs base                │
CellReset                            61.78n ± 6%   57.01n ± 4%   -7.71% (p=0.000 n=10)
FillFromFields/AllFields             58.48n ± 6%   44.02n ± 4%  -24.72% (p=0.000 n=10)
FillFromFields/AccountOnly           26.98n ± 2%   11.72n ± 3%  -56.57% (p=0.000 n=10)
FillFromFields/HashOnly              34.68n ± 1%   18.15n ± 2%  -47.66% (p=0.000 n=10)
DeferredUpdatePrefix/Sparse          38.32n ± 3%   39.55n ± 4%   +3.20% (p=0.035 n=10)
DeferredUpdatePrefix/Dense           89.66n ± 2%   90.61n ± 2%        ~ (p=0.172 n=10)
geomean                              47.59n        35.23n       -25.97%

                            │ baseline_opt_2.txt │         optimize_opt_2.txt          │
                            │        B/op        │    B/op     vs base                 │
CellReset                           0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
FillFromFields/AllFields            0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
FillFromFields/AccountOnly          0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
FillFromFields/HashOnly             0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
DeferredUpdatePrefix/Sparse         0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
DeferredUpdatePrefix/Dense          0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
geomean                                        ²               +0.00%                ²
¹ all samples are equal
² summaries must be >0 to compute geomean

                            │ baseline_opt_2.txt │         optimize_opt_2.txt          │
                            │     allocs/op      │ allocs/op   vs base                 │
CellReset                           0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
FillFromFields/AllFields            0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
FillFromFields/AccountOnly          0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
FillFromFields/HashOnly             0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
DeferredUpdatePrefix/Sparse         0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
DeferredUpdatePrefix/Dense          0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
geomean                                        ²               +0.00%                ²
¹ all samples are equal
² summaries must be >0 to compute geomean

[AskAlexSharov]

i don't understand this move

[Sahil-4555]

pendingPrefixes map holds a reference to the byte slice that serves as its key. The incoming prefix input specifies a shared, mutable scratch buffer (compactKeyBuf). If we send it directly to be.pendingPrefixes.Set(prefix) causes the map to keep a memory reference that will be overwritten on the next iteration of the folding loop, damaging the map's internal keys.

By invoking getDeferredUpdate first, we transfer the prefix bytes into the job's stable, isolated memory (update.prefixBuf). We then give upd.prefix to .Set(). Moving the call down here allows us to utilize the securely isolated byte slice as the map key, completely avoiding the aliasing problem and not needing to allocate a new copy

[AskAlexSharov]

also check last couple PR's here: https://github.com/erigontech/erigon/pulls/awskii

[Copilot]

Pull request overview

This PR targets allocation/memory reductions in the execution/commitment Hex Patricia trie hot paths, primarily around key compaction/encoding and cell (de)serialization during fold/unfold and hashing.

Changes:

• Added a caller-buffer-based HexToCompactBuf and switched fold/unfold branch-key encoding to reuse per-trie scratch buffers.
• Reduced per-cell/per-branch overhead by inlining cell.fillFromFields parsing and removing array clearing in cell.reset.
• Reduced deferred-update allocations by embedding a fixed prefix buffer inside pooled DeferredBranchUpdate objects.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

File	Description
execution/commitment/nibbles/nibbles.go	Adds HexToCompactBuf as a zero-allocation alternative to HexToCompact.
execution/commitment/hex_patricia_hashed.go	Reuses scratch buffers for compact keys, inlines deserialization parsing, and avoids some allocation patterns in hashing paths.
execution/commitment/commitment.go	Changes deferred branch update prefix handling to avoid per-update allocations by copying into an embedded buffer.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.