| RFC-0132：FIDL 資料表大小限制 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 這個 RFC 將 FIDL 資料表限制在最多 64 個項目。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 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 ns/field 和 63.7 ns/field。這表示未設定或保留的欄位費用約為 14.7 ns，而一組設定的欄位費用約為 63.7 ns。
當最大序數為 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 資料表的傳輸格式
如果資料表使用稀疏器表示法，大小限制的需求可能較少。