| 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 奈秒，所有欄位集的時間為 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 表格的線路格式
如果表格使用較稀疏的表示法，則可能較不需要大小限制。