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 process by which we compute split points for this table is naive, and mostly involves just computing the full subgraph size and using that to determine when to split, but this does not take into account how a table packs, e.g. that we can order things in such away as to not always expect an offset from the root object to reach the last thing packed.
I suspect that a slightly more careful calculation could reduce the number of required splits significantly, which would save 100s to 1000s of bytes, but also improve the overall efficiency of the packing code, which would need to handle fewer tables.
The text was updated successfully, but these errors were encountered:
On review there is less room for improvement here than I had thought, since the graph is shallow, and most of the size is taken up by the immediate children of each subtable. The situation has been improved by #610, and I think that's as good as we will get.
The process by which we compute split points for this table is naive, and mostly involves just computing the full subgraph size and using that to determine when to split, but this does not take into account how a table packs, e.g. that we can order things in such away as to not always expect an offset from the root object to reach the last thing packed.
I suspect that a slightly more careful calculation could reduce the number of required splits significantly, which would save 100s to 1000s of bytes, but also improve the overall efficiency of the packing code, which would need to handle fewer tables.
The text was updated successfully, but these errors were encountered: