You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EncodedChunksCacheEntry and PartialEncodedChunk have largely the same fields, but the former uses Hash Tables while the latter uses vectors of options. Since the key of the hash tables are part ordinal (which is bounded by 255) and shard IDs (which short-medium term are also bounded in low hundreds), vectors of options are actually acceptable to be used in place of hash tables, and thus EncodedChunksCacheEntry is redundant.
Also at least inside process_partial_encoded_chunk_request we create the cache entry from a partial encoded chunk to respond to the request, which is potentially expensive, and redundant if we can instead use a partial encoded chunk directly.
The text was updated successfully, but these errors were encountered:
The core concern this issue cares about is the performance of process_partial_encoded_chunk_request. This is taken care of in #2646 so I will close this now.
EncodedChunksCacheEntry
andPartialEncodedChunk
have largely the same fields, but the former uses Hash Tables while the latter uses vectors of options. Since the key of the hash tables are part ordinal (which is bounded by 255) and shard IDs (which short-medium term are also bounded in low hundreds), vectors of options are actually acceptable to be used in place of hash tables, and thusEncodedChunksCacheEntry
is redundant.Also at least inside
process_partial_encoded_chunk_request
we create the cache entry from a partial encoded chunk to respond to the request, which is potentially expensive, and redundant if we can instead use a partial encoded chunk directly.The text was updated successfully, but these errors were encountered: