Post

what if part of sync state was a small per-repo LRU cache of block CIDs? since most updates (at least with tid rkeys) stay on a few hot edges of the mst, maybe you could avoid sending most CIDs with most commits, just referencing a cache index instead

I think the issue with something like this is that the sender needs to know the receiver's cache size, and I don't think there's a good one-size-fits-all answer to cache size

see i’m curious about that, whether there’s a spot on the diminishing returns curve that’s pretty small and pretty effective that’s just Good Enough to pick and live with. maybe making efficiency sensitive to sorted rkey insertion order isn’t desirable though

0 reposts2 likes