Open tbg opened 2 weeks ago
Here's a picture from the vaults[^1], with some indication of which allocations could be avoided (fbs means flatbuffers here)
[^1]: jamboard link on this thread
Here's a more recent picture from master running oltp_write_only
.
allocs30s.pb.gz https://pprof.me/b820d13219711c30401cb7803f01bb01
We currently store raft entries in nested protobufs^1 (
RaftMessageRequest
containsraftpb.Message
contains[]Entry
contains in itsData []byte
field (after stripping a prefix) akvserverpb.RaftCommand
^2. This is all wildly inefficient, I think when we looked at it we found a ~12x allocation overhead (i.e. for one useful byte we allocated 12x as much).There are various ways to improve this, but one could be adding a new entry encoding in which we use a flatbuffer instead of
kvserverpb.RaftCommand
first (which removes the nested unmarshal), and later possibly replaceRaftMessageRequest
with a flatbuffer as well. However, unless we also use a flatbuffer codec for gRPC, we'll always do some inefficient unmarshaling.Epic: CRDB-42584
Jira issue: CRDB-44302