Я тестирую реализацию сериализации плоских буферов, но вижу гораздо большее отношение размера сериализованных данных к размеру необработанных данных. Я понимаю, что протокол предназначен для обеспечения обратной совместимости, и есть соображения выравнивания, которые вызывают некоторое раздувание. Однако после создания буфер примерно в 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 раза, исходя из того, как я структурировал эту схему? Возможно, это просто неизбежно из-за малого количества полей в данной таблице и большого количества элементов в векторах? Я попытался уменьшить проблемы с выравниванием, искусственно придав каждому типу переменных одинаковый размер (uint), и я попытался обойти таблицу взаимодействия и напрямую сделать таблицу событий вектором структур Position (что убрало бы часть обратной совместимости). что я ищу, если мне нужно будет внести изменения в будущем). Лучшее, что мне удалось снизить, это 1,7x. Это разумное количество дополнительных данных?





Да, есть накладные расходы на выравнивание, непрямые смещения, виртуальные таблицы и некоторые другие вещи. Вам лучше всего прочитать https://google.github.io/flatbuffers/flatbuffers_internals.html, чтобы получить представление об этом, что поможет в разработке минимально возможного представления.
Спасибо, что указали мне на этот документ. Я чувствую, что просмотрел всю другую документацию, кроме этого файла. Было очень полезно понять, что происходит под капотом. В конечном счете, тот факт, что мои данные представляют собой множество групп небольшого объема данных в сочетании с тем фактом, что полные 32-битные uints используются для смещений и информации о размере вектора, вызывает большую часть «дополнительных» данных, которые я видел. Я придумал несколько альтернатив, чтобы смягчить это. Спасибо!