| 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 绑定。
性能
本部分中的所有测量结果均以纳秒为单位，并且是在配备 Intel Core i5-7300U CPU @ 2.60GHz 的 NUC 上记录的。
以下内容显示了 LLCPP 单向通信所需的总（构建 + 编码 + 解码）用户模式时间：
无论是仅设置最后一个字段还是设置所有字段，这两种情况都非常接近线性，斜率分别为 14.7 纳秒/字段和 63.7 纳秒/字段。这意味着，未设置或预留的字段的费用约为 14.7 纳秒，而已设置的字段的费用约为 63.7 纳秒。
当最大序号为 64 时，最后一个字段设置时间为 3234.1 纳秒，所有字段设置时间为 6294.2 纳秒。
请注意，这些时间可能会随着绑定实现的变化而变化。
以下内容显示了 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 表的线格式
如果表格使用更稀疏的表示形式，则可能不太需要大小限制。