建構工具、編碼解碼微型基準測試
每個繫結都必須實作 Builder、Encode 和 Decode 基準。您可以對這些子步驟或變體進行基準化，但應有一個基準符合下列要求，以進行繫結對繫結比較。
Builder
這項基準會填入要傳遞至編碼器的物件繫結表示法。有時，建構這些物件的方法不只一種，一般準則是使用最快速的方法建構物件，同時仍要讓使用者覺得自然。您可以記錄不同建構工具技術的多個值，但應選擇一個做為比較的主要值。
設定
建構時間應不包含設定時間。當中只應包含建構所需的最低步驟數。
建立控點的時間視為設定時間，不計入建構工具基準。
解構函式
建構程序所需建立的物件，其解構函式應納入時間。任何額外的解構函式 (例如來自設定步驟的解構函式) 都應從建構工具時間中排除。
設定期間會建立控制代碼，但控制代碼是由建構的物件使用，且會在清除建構的物件時呼叫解構函式。
編碼
Encode 會取得建構階段建立的物件，並將其編碼為線路格式的位元組和控點。如 FIDL 線路格式所述，編碼必須驗證訊息。在此基準測試期間分配的緩衝區，應為繫結所需的最小大小。盡可能重複使用實際繫結程式碼，並遵循完全相同的步驟。
設定
編碼時間應不包含設定時間。其中只應包含編碼所需的最低步驟數。
解構函式
編碼程序需要建立的物件，其所有解構函式都應納入時間。建構或設定的解構函式 (包括在建構基準期間測量的建構物件) 應排除在外。也就是說，基準中不會包含控制代碼的建立時間和銷毀時間。
Decode
「解碼」會接收編碼的位元組和控制代碼，並將其解碼為適當的繫結物件。如 FIDL 線路格式所述，解碼時必須驗證訊息。在此基準測試期間分配的緩衝區，應為繫結所需的最小大小。解碼應盡可能重複使用實際繫結程式碼，並遵循完全相同的步驟。
設定
建構時間應不包含設定時間。當中只應包含建構所需的最低步驟數。
解構函式
解碼程序需要建立的物件，其所有解構函式都應計入時間。不應包含設定、建構或編碼中的任何其他解構函式。
測量
我們希望記錄每個基準的下列資訊：
- WallTime：以奈秒 (ns) 為單位的實際時間
- 配置：堆積配置數量
- AllocatedBytes：以位元組為單位的堆積分配位元組總數
- StackDepth：以位元組為單位的堆疊深度上限，也就是起始堆疊大小的最低點與達到的最大堆疊大小之間的差異
大多數最佳化作業都會以 WallTime 為主要重點，因此優先順序最高。不過，WallTime 會受到堆積分配數量的影響，尤其是非預期的分配，因此堆積分配是次要重點。除了最佳化 WallTime 之外，深層堆疊也是 Rust 的問題，可能也適用於 C++，因此在這些語言中，也應追蹤 FIDL 對堆疊深度的影響。
基準測試套件
基準化套件中的基準應易於說明、瞭解及討論。一般來說，這些資料應來自兩大類別：
- 有系統地建立合成基準。這些測試應隔離特定功能或功能組合，並選擇針對繫結中假設的弱點。基準的參數 (大小為元素數量) 應與其他基準相符，方便比較。
合成基準不應是任意組合的功能，否則很難判斷基準測量的內容、是否值得最佳化，以及測量結果對實際效能的影響。
合成基準測試的範例包括：含有 16、32、256、1024 個原始欄位的表格；大小為 16、32、256、1024 的位元組向量；以及含有交替配對或 uint8、uint64 的結構體。
- 以實際 fidl 型別為準。這些指標可評估實際環境中的效能。這些指標有助於進行前瞻最佳化和追蹤回歸。
迴歸基準的例子包括 fuchsia.io/File.ReadAt 回應，或是 fuchsia.posix.socket/DatagramSocket.SendMsg 要求。
GIDL 生成
GIDL 產生作業應從標準化基準集產生每個繫結的基準程式碼。
所有基準的規定
Chromeperf 整合
所有基準都應匯出至 chromeperf，並使用 test_suite: fuchsia.fidl_microbenchmarks。
Builder / Encode / Decode 基準測試的 Chromeperf 路徑
- 建構工具基準測試路徑
[Binding Flavour]/Builder/[Benchmark Path]/[Measurement] - 編碼基準路徑
[Binding Flavour]/Encode/[Benchmark Path]/[Measurement] - 解碼基準路徑
[Binding Flavour]/Decode/[Benchmark Path]/[Measurement]
範例：
Go/Builder/ByteArray/16/WallTime
繫結名稱為下列其中之一：LLCPP、HLCPP、Rust、Go、Dart (區分大小寫)
基準路徑是識別特定基準的字串。可以包含斜線，例如「ByteArray/1」。每個字都是大寫駝峰式大小寫。基準名稱和名稱的各個部分應為單數，例如 ManyStructField (而非 ManyStructFields)。
評估名稱為：WallTime、Allocations、AllocatedBytes、StackDepth (區分大小寫)
其他基準的 Chromeperf 路徑
結構為 [Overall Category]/[Specific Benchmark]/[Subbenchmarks]/[Measurements]。
一般來說，從最不具體的項目開始，越往右側越具體。
詳情如下：
- 如果基準與繫結相關，路徑應加上
[Binding Flavour]/前置字元 (例如Go/)。如果基準與特定繫結無關，則不應使用繫結前置字元 (例如Count/或Memcpy/)。如果基準效能繫結風味只有一個例項，則應加上繫結風味前置字元。 - 子基準 (例如大小) 會顯示在主要基準之後，從最重要到最不重要依序排列 (從左到右)。
- 子步驟會顯示在測量作業之前 (這是 C++ perftest 結構的必要條件)。
- 如果基準可能有多種評估類型，請指定評估類型。否則可以省略。
- 如果基準有參數，且參數名稱不明確或有多個參數，請指定參數名稱。如果很明顯，可以省略。參數名稱應為值的前置字串，且採用大寫駝峰式大小寫 (例如 Len256、Concurrency100)
例如：
LLCPP/Encode/ByteArray/16/Step.Encode/WallTime- 從繫結開始，然後輸入基準類型 (編碼)
- 基準測試名稱後方會顯示大小和子基準測試名稱 (16)
- 然後是子步驟名稱
- 最後，這項功能還提供
Go/Roundtrip/AsciiString/Len256/Concurrency100- 從繫結開始，然後是基準類型 (往返)
- 基準測試名稱後方會接續兩個具名子基準測試參數
- 無法評估，因為系統只會評估實際時間
Memcpy/ByteArray/16- 首先是基準類型。不適用，因此不具約束力
- 接著是基準和子基準名稱
- 由於系統只會評估實際時間，因此不會進行任何評估。
檔案路徑
基準應在 src/tests/benchmarks/fidl 中建立。如果基準程式碼的某個部分必須存在於其他位置，請盡力在 src/tests/benchmarks/fidl 中建立可執行檔和建構目標 (請參閱 Dart 中的包裝函式)。
建構工具/編碼/解碼基準可以存在於特定繫結目錄 src/tests/benchmarks/fidl/{go,rust,dart,hlcpp,llcpp} 中。
其他基準應放在與基準類型對應的子資料夾中，例如 src/tests/benchmarks/fidl/roundtrip。在極少數情況下，如果需要存取特定產生的型別，可以將這些型別放在其他位置 (例如 llcpp 內的 memcpy 基準，用來存取 llcpp 型別，測試大小正確的 memcpy)。這應視為技術債，並最終移至專屬的基準和資料夾。