Bug 1687095 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

With current structure, we cannot remove a certain lazy script data from XDR data with simple move/copy operation, because data is stored into multiple spans,
and removing an item breaks the remaining part's indices (or, if we don't shift the items, it doesn't affect the space).

So, to remove the space taken by lazy script, we need to decode XDR data, and then remove the data taken by the lazy script (while keeping the lazy script's index itself as placeholder), and renumber remaining things, and then re-encode it at linearlize step. This needs to be operated recursively for all delazifications.
And when decoding, we need to merge all stencils into one, while ignoring the removed data.
The cost would almost be same as just decoding, merging, and re-encoding all stencils at linearlize step.

Either way, it's not good because it's performed on main thread, and taking long there results in long interruption.

So, if we want to reduce XDR size with such way, we should think about offloading the linearlize, or the post-process work to helper thread.
With current structure, we cannot remove a certain lazy script data from XDR data with simple move/copy operation, because data is stored into multiple spans,
and removing an item breaks the remaining part's indices (or, if we don't shift the items, it doesn't affect the space).

So, to remove the space taken by lazy script, we need to decode XDR data, and then remove the data taken by the lazy script (while keeping the lazy script's index itself as placeholder), and renumber remaining things, and then re-encode it at linearlize step. This needs to be operated recursively for all delazifications.
And when decoding, we need to merge all stencils into one, while ignoring the removed data.
The cost would almost be same as just decoding, merging, and re-encoding all stencils at linearlize step.

Either way, it's not good because it's performed on main thread, and taking long there results in long interruption.

So, if we want to reduce XDR size with such way, we should think about offloading the linearlize or the post-process work to helper thread.

Back to Bug 1687095 Comment 2