| RFC-0113：高效率信封 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 這個 FTP 可為信封設計更精簡的編碼方式。 |
| 毛皮變化 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-06-21 |
| 審查日期 (年-月-日) | 2021-07-21 |
「將信封轉換成明信片」
摘要
這個 RFC 提出了更精簡的 FIDL 編碼方式1。
提振精神
信封是可擴充可擴充資料結構的基礎 (資料表和可延伸聯集)。 更簡潔有效率的信封格式，可以 可擴充的結構，以便在效能較高的情況下使用 以及電線大小？
設計
您提議的信封格式請參考下列 C 結構：
struct Envelope {
uint32_t byte_size;
uint32_t handle_count;
};
與現有的信封格式比較：
- 位元組大小欄位會維持不變 (32 位元)。
- 大小包括可遞迴的子物件大小 編碼。
- 舉例來說，
vector<string>的大小包含 外部字串子物件 - 這與目前信封的現有行為相符 大小欄位中的值
- 帳號代碼數量欄位維持不變 (32 位元)。
- handle_count 包含所有遞迴的控制代碼數量 子物件。
- 系統會捨棄在家狀態/不存在欄位。
- 談吐與儀態會以非零的值， handle_count 欄位。
- 缺席是以大小和處理計數欄位的值都是零
- 這就是所謂的零信封。
- 零信封等於
FIDL_ALLOC_ABSENT。
- 驗證位元組大小欄位
- 位元組大小欄位必須通過驗證為 8 的倍數。
解碼器可能會用指標覆寫信封中的資料 假設他們知道信封內容的靜態類型 (結構定義)。 如需相關操作說明，請參閱「不明資料」一節 如果內容類型不明，就會處理信封。
已編碼/解碼表單的 C/C++ 結構
信封已編碼或解碼的信封形式可以稱為 C 聯集：
typedef union {
struct {
uint32_t byte_size;
uint32_t handle_count;
} encoded;
void* data;
} fidl_envelope_t;
static_assert(sizeof(fidl_envelope_t) == sizeof(void*));
不明資料
接收器 - 驗證工具與因此可能不知道 用於可改良的資料結構。 如果接收者不知道型別，信封的可能就是最基本的剖析 並略過
- 信封大小會決定要略過的閒置資料量。
- 如果信封的帳號代碼數不為 0，驗證工具就「必須」儲存 或閉上各把手
- 解碼器「可能」會覆寫未知信封，並指向
信封的內容 (如果想就地解碼)。
- 如果解碼器確實以指標覆寫信封，就會遺失 檔案大小與處理信封中的數量資訊。 繫結 MAY 可提供解碼器的機制，以儲存大小和 在覆寫信封前處理計數資訊；本 RFC 並不代表這類機制的運作原理。
執行策略
這個 RFC 是變更線路格式變更。
我們必須透過複雜的線路格式遷移，才能邁向高效率的遷移方式 信封。這項電匯格式變更將與其他遷移作業結合 ，可降低每項功能的遷移成本。
回溯相容性
建議的有線格式變更是與 API (來源) 相容。 任何手動添加的 FIDL 代碼都需更新才能處理新線 格式。
線路格式變更與 ABI 不相容。
成效
這項成效評估工具的執行位置是 CL， 設計出有效率的信封實作原型在這個測試中 資料表建立了所有欄位。其他輸入內容產生的結果類似。
以下時間以奈秒表示。沒有有效率信封的時間是 ，而有有效率的信封時間位於箭頭後面。
| # 欄位 | 編碼 | 解碼 |
|---|---|---|
| 16 | 64 ->40 人 | 176 ->146 人 |
| 64 | 165 ->121 人 | 321 ->221 人 |
| 256 | 567 ->368 | 923 ->527 人 |
| 1024 | 2139 ->1429 人 | 3284 ->1636 年 |
根據輸入內容不同，使用有效率的信封似乎快了 1.1 至 2 倍
人體工學
- 可擴充的資料結構更有效率 在效率至關重要的情況下，使用者需要擔心 而且還能享有擴充性 他們先前需要使用無法擴充的結構
- 我們也可能會建議
建議保留 FIDL 資料結構和結構體以求高效能
定義。
- 已嘗試擴充的聯集 (RFC-0061) 移除靜態聯集。
說明文件
- 電線格式說明文件必須更新。
- 更新說明文件時，您應將信封解釋為 第一級概念：這能提升認知能力 這時讀者遇到 選用性和可擴展資料結構
- 我們應該更新 FIDL 樣式指南，以在 應使用可擴充類型
安全性
這個 RFC 應該不會對安全性造成影響。
這個 RFC 將移除
否則可以在舊格式的大小和指標中複製。
先前，您可能會收到一個信封大小/把手，而不是零大小/把手
FIDL_ALLOC_ABSENT，或是大小/帳號代碼和 FIDL_ALLOC_PRESENT 為零。
先前不必進行額外驗證檢查。
您無法判斷信封是採用線路形式， 單靠資料才能產生去模糊化的形態這不構成問題，因為 練習在繫結中一定會有各自的記帳 追蹤訊息是採用電匯還是解碼格式。
隱私權
這個 RFC 應該不會對隱私權造成任何影響。
測試
- 由於這個 RFC 會變更信封的線路格式，因此我們認為 現有 FIDL 測試套件，尤其是相容性測試 - 要充分測試使用信封的所有情境。
- 如果我們同意變更電線格式變更，並視為柔性轉換，請參閱 導入策略一節) 中，新增 測試夥伴後再討論，或許也可能需要改用新的通訊格式。
缺點、替代方案和未知
只要我們認為， 此提案不具導入成本。
先前的 RFC 拒絕和引數立即核准
這個 RFC 先前遭拒絕，並基於以下理由而遭拒 (複製 才能重新送審：
2019 年 2 月 21 日，此 RFC 最初已獲接受。FIDL 團隊致力於 固定電線格式，以因應 2019 年大半年的需求 而且範圍涵蓋第 3 季和第 4 季。遷移作業完成日期 2019 年 12 月 1 日。
穩定計畫涵蓋多項變更：
- 主要 RFC-0061：可延伸聯集
- RFC-0032: 效率信封，也就是這個 RFC
- RFC-0037：交易郵件標頭 v3
- RFC-0048：明確聯合序數
然而，隨著工作尚未結束，而在 12 月 1 日的期限已久， FIDL 團隊決定不執行有效的信封變更， 更傾向於 2020 年推動這項計畫。與一部分的其他變更不同 而效率高的信封只是記憶體容量的一種 儲存量相當小，如果與市場其他指標相比 FIDL 線格式 (例如資料表的密集格式)。 「延遲」的計算方式是將範圍縮小 及時完成所有工作的機率有所改善所以 FIDL 團隊 工作排程
我們現在很快就要延後 18 個月 信包 長者遺忘。2020 年的卓越成效研究證明 則不會產生實質影響
事實是，這一切終將是沒事。已拒絕。
為何要立即重新核准？
FIDL 團隊目前計劃批次彙整多種線路格式 然後一次遷移所有變更也就是說 能夠以較低的成本增加高效率信封的支援 這類費用與其他遷移作業共用)。
此外，現在也會提供 成效提升的具體數據 有效的信封和收穫相當重要
基於這些因素，現在正是重新執行此 RFC 和 實際執行這些工作
既有藝術品和參考資料
這個 RFC 是 rfc-0026 的刪減版本，自該版本起已遭拒 整個 RFC 都沒有足夠的共識