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
Right now our PackedCounter design only supports 5 dynamic fields per table. We could maybe up this to 6 dynamic fields if we got rid of the total byte length (#1420).
An alternative approach could be RLP inspired, where the first byte in PackedCounter is the length of the PackedCounter itself (in bytes or in 32-byte words).
This would mean for the first 4 dynamic fields, we'll have the ~same gas. And for one extra storage read (for retrieving single field) and n-1 storage reads (for retrieving the whole record, where n is the word length of the PackedCounter), we could support an arbitrary number of dynamic fields.
The text was updated successfully, but these errors were encountered:
in terms of storage reads this should be pretty similar to separating into different tables (since we still need to read one word per 5 or 6 dynamic fields)
for the StoreSpliceRecord event we'd need to emit a dynamic bytes field for the packed counter (probably shouldn't because it would mean we have to read all slots of the packed counter even if we only needed one of the slots to update a single dynamic field) or have some additional context on the event for "which part of the packed counter was updated"
with this design a "total length" field might be more important to avoid having to read all the slots and summing lots of individual lengths to get the total length
if we store the total length in bytes eg. at the start, we'd need to write two slots when modifying the length of a field whose length is not stored in the first slot. We probably should avoid this because sstore is pretty expensive.
alternatively we store a "total length per word of packed counter" in each word to avoid having to write two separate slots, but that doesn't solve the issue of having to read multiple slots and summing to get the total length, so we might as well just get rid of storing the length accumulator
agree it would be a better dev experience if devs don't have to think about splitting tables to support more than 5 dynamic fields
Right now our PackedCounter design only supports 5 dynamic fields per table. We could maybe up this to 6 dynamic fields if we got rid of the total byte length (#1420).
An alternative approach could be RLP inspired, where the first byte in PackedCounter is the length of the PackedCounter itself (in bytes or in 32-byte words).
This would mean for the first 4 dynamic fields, we'll have the ~same gas. And for one extra storage read (for retrieving single field) and n-1 storage reads (for retrieving the whole record, where n is the word length of the PackedCounter), we could support an arbitrary number of dynamic fields.
The text was updated successfully, but these errors were encountered: