Reduce memory usage of the static flatbuffer API
This contains a couple of changes, which work together and are a bit
hard to separate out.
1) Instead of requiring the whole contents of a sub-message or vector to
be aligned, split the alignment requirement up into an alignment
requirement at an offset into the message. This lets us leave the
length field in a message, for example, at 4 byte alignment when the
body requires 8 byte alignment. This enables better packing of
fields.
2) From James, don't pre-reserve space for vectors with 0 length. They
will trigger a re-allocation anyways when they are used since there
is no space allocated, so pre-allocating doesn't help.
3) Remove padding at the end of messages and require the allocator to
handle it instead. We used to allocate kSize + kAlign and then
manually align things, which resulted in wasted space.
4) Automatically add any extra padding after a vector to the vector.
For some small vectors, this lets us use the padding for the vector
rather than allocating more space.
5) Shrink the code generated for the object offsets by adding constexpr
variables with the previous object size rather than inlining it.
This results in a much faster build since clang-format was fighting
the large fields at build time.
6) Sort fields in a flatbuffer by alignment to pack them better.
Change-Id: I5af440855e3425be31fa7f30c68af552fcf06cb2
Signed-off-by: Austin Schuh <austin.schuh@bluerivertech.com>
Signed-off-by: James Kuszmaul <james.kuszmaul@bluerivertech.com>
diff --git a/aos/flatbuffers/static_table.h b/aos/flatbuffers/static_table.h
index e9619a7..a7f96d1 100644
--- a/aos/flatbuffers/static_table.h
+++ b/aos/flatbuffers/static_table.h
@@ -17,7 +17,13 @@
// Every table will be aligned to the greatest alignment of all of its members
// and its size will be equal to a multiple of the alignment. Each table shall
// have the following layout: [vtable offset; inline data with padding; vtable;
-// padding; table/vector data with padding]
+// table/vector data with padding]
+//
+// Within the table/vector data with padding section, there will be a chunk of
+// memory for the data associated with each sub-table/vector of the table.
+// That memory will start with some padding and then the memory actually
+// allocated to the table/vector in question will start at said
+// sub-table/vector's individual alignment.
class Table : public ResizeableObject {
public:
// Prints out a debug string of the raw flatbuffer memory. Does not currently
@@ -57,7 +63,6 @@
virtual size_t VtableSize() const = 0;
virtual size_t InlineTableSize() const = 0;
virtual size_t OffsetDataStart() const = 0;
- size_t AbsoluteOffsetOffset() const override { return 0; }
void PopulateVtable() {
// Zero out everything up to the start of the sub-messages/tables, which are
// responsible for doing their own memory initialization.