Flatbuffer 线尺寸大于预期
Flatbuffer wire size larger than expected
我正在测试平面缓冲区序列化实现,但我发现序列化数据大小与原始数据大小的比率要大得多。我意识到该协议旨在允许向后兼容,并且存在导致一定程度膨胀的对齐注意事项。但是,一旦构建,缓冲区大约是我放入其中的原始数据大小的 2 倍。这对我来说似乎很大,我怀疑它与我构建模式的方式有关。这是我理想情况下使用的架构。它允许灵活性,并且对我试图表示的信息类型具有良好的逻辑意义。
// IDL file
namespace Data;
// Structs \
struct Position {
x :short;
y :short;
z :short;
}
// Tables \
table Interaction {
pos :Position;
value :uint;
}
table Event {
interactions :[Interaction]; // 1-3 interactions are typical in a given event, but could be as high as 30
id :ubyte=255;
time1 :uint;
time2 :ulong;
}
table Packet {
events1 :[Event]; // 1000s or more are typical in a given Packet
events2 :[OtherEvent1]; // Other events that would be defined but occur much less frequently than events1
events3 :[OtherEvent2]; // Other events that would be defined but occur much less frequently than events1
}
root_type Packet;
根据我构建此模式的方式,是否需要 2 倍的线径?它可能只是 inetable 因为给定 table 中的字段数量少而向量中的元素数量多?我试图通过人为地使每个变量类型具有相同的大小 (uint) 来减少对齐问题,并且我尝试绕过交互 table 并直接使事件 table 具有位置结构的向量(其中如果我将来需要进行更改,将会消除我正在寻找的一些向后兼容性)。我能够将比率降至 1.7 倍的最佳值。这是合理数量的额外数据吗?
是的,在对齐、间接偏移、vtables 和其他一些事情上有开销。您最好阅读 https://google.github.io/flatbuffers/flatbuffers_internals.html 以了解这些内容,这将有助于设计尽可能小的表示。
我正在测试平面缓冲区序列化实现,但我发现序列化数据大小与原始数据大小的比率要大得多。我意识到该协议旨在允许向后兼容,并且存在导致一定程度膨胀的对齐注意事项。但是,一旦构建,缓冲区大约是我放入其中的原始数据大小的 2 倍。这对我来说似乎很大,我怀疑它与我构建模式的方式有关。这是我理想情况下使用的架构。它允许灵活性,并且对我试图表示的信息类型具有良好的逻辑意义。
// IDL file
namespace Data;
// Structs \
struct Position {
x :short;
y :short;
z :short;
}
// Tables \
table Interaction {
pos :Position;
value :uint;
}
table Event {
interactions :[Interaction]; // 1-3 interactions are typical in a given event, but could be as high as 30
id :ubyte=255;
time1 :uint;
time2 :ulong;
}
table Packet {
events1 :[Event]; // 1000s or more are typical in a given Packet
events2 :[OtherEvent1]; // Other events that would be defined but occur much less frequently than events1
events3 :[OtherEvent2]; // Other events that would be defined but occur much less frequently than events1
}
root_type Packet;
根据我构建此模式的方式,是否需要 2 倍的线径?它可能只是 inetable 因为给定 table 中的字段数量少而向量中的元素数量多?我试图通过人为地使每个变量类型具有相同的大小 (uint) 来减少对齐问题,并且我尝试绕过交互 table 并直接使事件 table 具有位置结构的向量(其中如果我将来需要进行更改,将会消除我正在寻找的一些向后兼容性)。我能够将比率降至 1.7 倍的最佳值。这是合理数量的额外数据吗?
是的,在对齐、间接偏移、vtables 和其他一些事情上有开销。您最好阅读 https://google.github.io/flatbuffers/flatbuffers_internals.html 以了解这些内容,这将有助于设计尽可能小的表示。