建構工具、編碼 Microbenchmark
每個繫結都必須實作建構工具、編碼和解碼基準。您可以對這些子步驟或變化版本進行基準測試，但應有一個基準符合以下繫結至繫結比較的要求。
Builder
這個基準測試會填入會傳遞到編碼器的物件表示法繫結。有時候，建構這些物件的方法有很多種，一般而言，我們會以最快速的方式建構物件，但對使用者來說仍顯而易見。您可以針對不同的建構工具技術記錄多個值，但應選擇其中一個做為比較的主要值。
設定
建構時間應排除設定時間。其中只應包含建構所需的最少步驟。
帳號代碼建立時間視為設定時間，並不包含在建構工具基準中。
破壞者
建構程序需要建立物件的所有解構函式都應該加入時間。其他的刪除工具 (例如設定步驟中的步驟) 均應從建構工具時間中排除。
雖然系統會在設定期間建立控點，但已建構的物件會取用這個控制代碼，而當建構的物件清除後，系統會呼叫解構函式。
編碼
編碼會接收建構工具階段建立的物件，並將其編碼為線格式位元組和控制代碼。如 FIDL 線格式所述，編碼必須驗證訊息。在這個基準測試期間配置的所有緩衝區，應為繫結要求的最小大小。編碼應重複使用，並盡可能採取與實際繫結程式碼完全相同的步驟。
設定
請勿在編碼時間中排除設定時間。其中只需包含編碼所需的最少步驟。
破壞者
為編碼程序建立的物件應加入任何解構函式。應排除建構或設定的解構，包括在建構基準測試期間測量的已建構物件。也就是說，既然程序建立時間和刪除時間都不會納入基準測試中。
解碼
解碼會接收經過編碼的位元組，並處理這些位元組並將其解碼至適當的繫結物件。如 FIDL 電匯格式所述，解碼時必須驗證訊息。在這個基準測試期間配置的所有緩衝區，應為繫結要求的最小大小。解碼應重複使用，並盡可能遵循與實際繫結程式碼相同的步驟。
設定
建構時間應排除設定時間。其中只應包含建構所需的最少步驟。
破壞者
為解碼程序建立的物件應加入任何解構函式。請勿加入任何因設定、建構或編碼而產生的其他解構。
測量
我們希望記錄各個基準：
- WallTime：實際時間，以奈秒表示 (ns)
- 分配：計為 # 個堆積分配量
- 分配位元組：分配的堆積總位元組數 (以位元組為單位)
- StackDepth：堆疊深度上限 (以位元組為單位)，亦即比較起始堆疊大小最低點與達到的堆疊大小上限之間的差異
WallTime 是大部分最佳化作業的重點，因此系統會優先使用 WallTime。不過，WallTime 會受到堆積分配量 (尤其是非預期分配) 的影響，因此是次要關注的重點。除了針對 WallTime 進行最佳化，深度堆疊是 Rust 的問題，也可能發生在 C++ 上出現的問題，因此對於這些語言而言，FIDL 對堆疊深度的貢獻也應一併追蹤。
基準套件
基準套件中的基準應以簡單易懂的方式說明、理解及探討相關問題，他們通常應同時分為兩類：
- 以特定方法建立合成基準。這類區隔應區隔特定功能或特徵組合，再選擇要針對繫結中的假設弱點。基準的參數，且選擇元素數量時應符合其他基準，以便與其他基準進行比較。
綜合基準「不應」是功能的任意組合，因此很難判斷所測量的項目是否值得最佳化，或是評估對實際成效的影響。
合成基準範例包括具有 16、32、256、1024 個原始元欄位的資料表、大小為 16、32、256、1024 的位元組向量、具有交錯組合的結構體或 uint8、uint64。
- 根據實際纖維類型進行基準測試。這些測量的是外部設備的效能。這對於前瞻性最佳化和追蹤迴歸都很實用。
迴歸基準範例包括 fuchsia.io/File.ReadAt 回應或 fuchsia.posix.socket/DatagramSocket.SendMsg 要求。
GIDL 產生
產生 GIDL 時，應從標準化的一組基準測試產生每個繫結的基準程式碼。
所有基準的規定
Chromeperf 整合功能
所有基準測試都應匯出至 chromeperf，並使用 test_suite：fuchsia.fidl_microbenchmarks。
建構工具 / 編碼 / 解碼基準的 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++ 效能結構的必要條件)。
- 如果基準可能有多種評估類型，就必須指定評估類型。否則可以省略。
- 如果有基準專用參數，則必須指定參數名稱不明確或有多個參數。如果標示明顯，則可省略。參數名稱應該在值前面加上大寫英文字母，例如 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 類型，以測試正確大小的 ccpp 值)。這應該視為技術債，最終會移至專屬的基準和資料夾。