| 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 绑定进行更改。
性能
本部分中的所有测量结果均以纳秒为单位，并在 NUC 上记录，采用 Intel Core i5-7300U CPU 2.60GHz。
下面显示了单向通信所需的总（构建 + 编码 + 解码）用户模式时间（针对 LLCPP 测量）：
仅设置了最后一个字段且设置了所有字段的两种情况都非常接近线性，其斜率分别为 14.7 纳秒/场和 63.7 纳秒/场。这意味着，未设置或预留的字段的费用大约为 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 表的有线格式支持
如果表使用稀疏表示法，则对大小限制可能的需求不大。