feat: cache data hash to optimize performance for empty blocks #2616
Conversation
This optimization addresses the performance issue where hash calculation for empty blocks becomes costly when called repeatedly. The solution: - Adds private cachedHash field to Data struct - Uses thread-safe caching with RWMutex for concurrent access - Automatically invalidates cache when data changes via FromProto - Maintains backward compatibility with existing API Co-authored-by: Marko <[email protected]>
|
The latest Buf updates on your PR. Results from workflow CI and Release / buf-check (pull_request).
|
| @@ -93,6 +93,7 @@ message Metadata { | |||
| message Data { | |||
| Metadata metadata = 1; | |||
| repeated bytes txs = 2; | |||
| bytes cached_hash = 3; // Optional cached hash for performance | |||
There was a problem hiding this comment.
Do we really need to add this? Just caching the last one in the manager is sufficient right? Sure it is less optimized that cache it for all, but the logic that omits the cache for the serialization can be confusing if you use the api directly .
There was a problem hiding this comment.
in the flow, every time we get we would rehash since we rarely to almost never keep the data struct alive for multiple checks on the hash after we get from the DB. This would make the hash cache nullified, evaluating if this cache is worth it if we remove it from the proto
There was a problem hiding this comment.
don't we only care about height-1 anyway?
This optimization addresses the performance issue where hash calculation for empty blocks becomes costly when called repeatedly.
Changes
Performance Impact
Eliminates expensive marshaling + SHA256 operations for repeated hash calls on the same data, particularly beneficial for empty blocks.
Closes #2612
Generated with Claude Code