| RFC-0132：FIDL 表大小限制 | |
|---|---|
| 状态 | 已接受 |
| 区域 |
|
| 说明 | 此 RFC 将 FIDL 表的条目数限制为最多 64 个。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-09-20 |
| 审核日期（年-月-日） | 2021-10-04 |
摘要
此 RFC 将 FIDL 表的成员数限制为最多 64 个。
另请参见：
设计初衷
发送 FIDL 表（构建、编码和解码）的用户模式性能开销取决于表正文中的最大集序数。这种行为对用户来说并不明显或直观，如果滥用，可能会产生负面性能影响。此 RFC 提出了一项限制，以防止近期出现严重行为，作为权宜解决方案，促使 FIDL 作者重新考虑其设计，并鼓励 FIDL 团队在 FIDL 作者开始遇到限制时提供更好的长期答案。
利益相关方
哪些人对此 RFC 的接受与否有利益相关？
协调员：pascallouis@google.com
审核者：pascallouis@google.com、yifeit@google.com、mkember@google.com
咨询了以下人员：ianloic@google.com、azaslavsky@google.com、abarth@google.com
社交：不适用
设计
表最多只能包含 64 个序数。具体而言：
- 如果序数值高于 64，FIDL 编译器必须发出错误。
- 当收到高于 64 的序数时，绑定不得出错。 它们可以忽略大于 64 的序数。
此外，如果第 64 个序数未预留，则必须包含另一个表，以确保消息能够继续扩展。具体而言，如果第 64 个序数不是预留的，并且被分配了非表类型，FIDL 编译器必须发出错误。
实现
这需要更改 FIDL 编译器以及每个 FIDL 绑定。
性能
本部分中的所有测量结果均以纳秒为单位，是在搭载 2.60GHz Intel Core i5-7300U CPU 的 NUC 上记录的。
以下是 LLCPP 测量的一方向通信所需的用户模式总时间（构建 + 编码 + 解码）：
仅设置最后一个字段和设置所有字段的情况都非常接近线性，其斜率分别为 14.7 ns/field 和 63.7 ns/field。这意味着，未设置或未使用的字段的开销约为 14.7 纳秒，而已设置的字段的开销约为 63.7 纳秒。
当最大序数为 64 时，最后一个字段设置时间为 3234.1 ns，所有字段设置时间为 6294.2 ns。
请注意，这些时间可能会随着绑定实现的变化而发生变化。
下表显示了 Fuchsia 系统中 FIDL 表定义中的最大非预留序数的当前分布：
表格定义中的最高序数为 56，其次为 26。包含 56 个字段的表中有许多字段被不必要地标记为已预留，可以重构为更紧凑的表。这意味着，在未来一段时间内，当前表通常不会达到 64 个序数的限制。
分配更小
某些绑定（例如 LLCPP）会计算消息所需的最大缓冲区大小，并使用此信息来调整分配大小。如果表不再是无限大小，在某些情况下，可以缩减分配的大小，这可能会提高性能。
工效学设计
此 RFC 会使 FIDL 的使用变得更加困难，因为现在必须考虑限制。
向后兼容性
此 RFC 会破坏与条目数超过 64 的表的向后兼容性。
安全注意事项
这不会产生任何安全影响。
隐私注意事项
这不会对隐私造成影响。
测试
GIDL 测试将验证线格格式是否保持不变，以及大于 64 个条目的表的解码是否仍能正常运行。单元测试将检查编译器级更改。
文档
需要更新 FIDL 语言文档，以指明此限制。
缺点、替代方案和未知情况
为什么上限是 64 个？
64 这个上限是任意设定的，但之所以选择这个上限，有以下几点原因：
这比绝大多数用例所需的大小要大。虽然会出现离群值，但可以使用其他结构来表示数据。如果将此限制改为 32，则会更接近目前常用的表大小。
如果上限大于 64，那么在某些情况下，用户可能会对性能下降感到意外。如果发现更高的限制更常用，我们仍有可能通过另一个 RFC 再次提高限制。
64 是 64 位整数中的位数。这样一来，绑定就可以使用位标志来标记存在或不存在。同样，位掩码可用于查找序数，如已遭拒 RFC RFC-0016 中所述。
大型表的替代方案
您可以使用多种替代结构来替代大型表。联合体矢量就是其中一种选项，它与表一样可扩展，但对联合体字段的数量没有限制。它还具有一种表示法，可能更适用于使用场景中字段的使用较为稀疏的情况。
稀疏表布局
之前被拒的 RFC 探讨了一种可实现更简洁表示的表格替代布局： RFC-0116：对更简洁的 FIDL 表的线格格式支持
如果表使用更稀疏的表示法，则可能不需要设置大小限制。