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
The object retrieval code downloads one or two pieces to determine how long an object is. But the archiver can read the length of the object from the block data.
Including the object length in the block data would improve object fetching latency, because all the object's pieces could be downloaded at the same time.
As part of this change, mappings could use the offset of the first data byte, rather than the offset of the encoded length. This would save us 1 downloaded piece, in some rare edge cases.
The object retrieval code downloads one or two pieces to determine how long an object is. But the archiver can read the length of the object from the block data.
Including the object length in the block data would improve object fetching latency, because all the object's pieces could be downloaded at the same time.
As part of this change, mappings could use the offset of the first data byte, rather than the offset of the encoded length. This would save us 1 downloaded piece, in some rare edge cases.
See #3318 and #3362 for more background.
Implementation Strategy
The object mappings are initially generated by the runtime, then modified by the archiver. To apply to all blocks, the archiver should:
Updating the runtime code would only add the length to mappings for new blocks.
The text was updated successfully, but these errors were encountered: