-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Storage Execution
-
Storage Execution 2026-08-03, Storage Execution 2026-08-17, Storage Execution 2026-08-31
-
None
-
None
-
None
-
None
-
None
-
None
-
None
ValidateAdaptor computes a SHA256 hash per record (and per index/catalog entry) while iterating an entire collection. Each SHA256Block::computeHash call heap-allocates and frees a fresh EVP_MD_CTX (EVP_MD_CTX_new/EVP_MD_CTX_free) and re-binds the digest on every call. For the small inputs typical of _id fields and documents, this per-call context lifecycle is on the same order as the actual hashing, so validation pays avoidable alloc/init/free overhead once or twice per record across the whole collection.
The codebase already has this optimization for HMAC computeHmacWithCtx, but no equivalent exists for plain hashing.
Hot call sites (all single-threaded sequential loops):
- per record for individual document hash
- per catalog/index ident
- per entry record for the whole collection hash
Proposed change
Create a DigestContext and a computeHashWithCtx API mirroring HmacContext/computeHmacWithCtx. Convert the ValidateAdaptor loops to hold one DigestContext and call computeHashWithCtx.