使用更扁平模式的性能影响

Question

我正在使用 FlatBuffers (C++) 来存储有关文件的元数据信息。这包括 EXIF、IPTC、GPS 和各种其他元数据值。

在我当前的模式中，我有一个相当规范化的定义，上面列出的每个组都有自己的表。根表只包含每个子表的属性。

基本示例：

table GPSProperties {
  latitude:double;
  longitude:double;
}

table ContactProperties {
  name:string;
  email:string;
}

table EXIFProperties {
  camera:string;
  lens:string;
  gps:GPSProperties;
}

table IPTCProperties {
  city:string;
  country:string;
  contact:ContactProperties;
}

table Registry {
 exifProperties:EXIFProperties;
 iptcProperties:IPTCProperties;
}

root_type Registry;

这可行，但是构建缓冲区时的嵌套限制开始使代码变得非常混乱。同样，将属性分解为单独的表只是为了在架构中清晰。

我正在考虑将整个架构“扁平化”到一个表中，但我想知道这样做是否会影响性能或内存。这个单一的表可能有几百个字段，但大多数都是空的。

建议：

table Registry {
  exif_camera:string;
  exif_lens:string;
  exif_gps_latitude:double;
  exif_gps_longitude:double;
  iptc_city:string;
  iptc_country:string;
  iptc_contact_name:string;
  iptc_contact_email:string;
}

root_type Registry;

由于未设置或设置为其默认值的属性不会占用任何内存，我倾向于相信扁平化架构可能不会有问题。但我不确定。

（请注意，性能是我最关心的问题，其次是内存使用情况。规范化模式的性能非常好，但我认为扁平化模式确实有助于我清理代码库。）

Answer 1

你应该首先清楚的基本知识：

1. 每个表的顶部都有一个 vtable，它告诉可以找到表的每个字段的偏移量。如果一个表的字段太多，不管你存不存数据，这个vtable都会变大。

2. 如果您尝试创建表的层次结构，则会创建额外的 vtable，并且还会增加设计的间接成本。

3. 如果在多个对象中存储了类似的数据，则 vtables 也是共享的。就像您正在创建仅使用 exif_camera 变量的对象！

因此，这取决于您的数据是否庞大且异构，是否使用更有条理的层次结构。但是，如果您的数据是同质的，则更喜欢扁平表。

Answer 2

由于您的大部分数据都是字符串，因此这两种设计的大小和速度将非常相似，因此您可能应该根据软件工程的角度来选择更适合您的数据。

也就是说，平面版本在大小上可能会稍微更有效（更少的 vtables），而且访问速度肯定会更快（尽管再次强调，这是微不足道的，因为它主要是字符串数据）。

平面版本效率较低的唯一方法是，如果您将大量数据存储在一个缓冲区中，其中设置的字段在每个表之间差异很大。那么non-flat版本可能会产生更多的vtable共享。

在非平面版本中，如果字段不太可能发生变化，GPSProperties 之类的表可能是 struct，这样会更有效。

Answer 3

这个表可能有几百个字段，但大多数字段会 为空。

性能成本可能很小，您不会注意到，但对我来说，您上面的报价是决定使用哪种设计的摇摆因素。

当其他人在谈论 vtables 的成本时；我根本不会担心这个。每个类有一个 vtable，每次运行准备一次，不会很贵。 然而，拥有 100 个空且未使用的字符串将非常昂贵（内存使用方面）并且会消耗您创建的每个对象；此外，读取您的字段将变得更加复杂，因为您不能再假设您读取的类的所有数据都在那里。

如果大多数/所有字段始终存在，那么我可以看到制作单个课程的吸引力；但他们不是。