建構工具、Encode Decode Microbenchmarks
每個繫結都必須實作一個建構工具、編碼和解碼基準測試。您可以針對這些子步驟或變化版本進行基準測試，但至少要有一個基準符合以下條件，才能進行繫結與繫結的比較。
Builder
這項基準測試會將要傳遞至編碼器的物件繫結方式填入繫結的表示法。有時可以透過多種方式建構這些物件，通用指南就是盡可能快速地建構物件，對使用者來說仍屬自然。您可以記錄不同建構工具技術的多個值，但應選擇一個做為比較的主要值。
設定
設定時間不可從建構時間中排除。其中只應包含建構所需的最少步驟。
處理建立作業會將建立時間視為設定時間，而且未包含在建構工具基準中。
解構
建立用於建構程序所需的物件刪除器都應附在時間內。任何額外解構函式 (例如設定步驟的操作) 都應從建構工具時間中排除。
控點是在設定期間建立，而控點會由建構的物件使用，當建構的物件清理完成後，系統會呼叫解構函式。
編碼
編碼作業會擷取由建構工具階段建構的物件，並將其編碼成傳輸格式的位元組及處理代碼。如 FIDL 傳輸格式中指定的方式，編碼必須驗證訊息。在此基準測試期間分配到的任何緩衝區，都應是繫結所需的最小大小。編碼應重複使用，並盡可能按照與實際繫結程式碼相同的步驟操作。
設定
設定時間不可從編碼時間中排除。你應該只加入編碼作業所需的最少步驟組合。
解構
為編碼程序建立物件所需的任何解構函式，都應加入時間點。應排除建構或設定的解構函式，包括在建構基準測試期間測量的建構物件。也就是說，基準測試不包含處理建立時間和刪除時間。
解碼
解碼器會接收已編碼的位元組，然後處理並解碼至適當的繫結物件。根據 FIDL 傳輸格式中指定的方式，解碼必須驗證訊息。在此基準測試期間分配到的任何緩衝區，都應是繫結所需的最小大小。解碼器應盡可能重複使用，並盡可能遵循與實際繫結程式碼相同的步驟。
設定
設定時間不可從建構時間中排除。其中只應包含建構所需的最少步驟。
解構
為進行解碼程序而建立物件所需的任何解構函式，均應加入時間中。不得包含在設定、建構或編碼過程中的額外解構函式。
測量
我們想針對每項基準記錄記錄：
- WallTime：實際時間，以奈秒為單位 (ns)
- 分配：# 堆積分配數量做為計數
- 分配位元組：分配的堆積總位元組數 (以位元組為單位)
- StackDepth：堆疊深度上限 (以位元組為單位)，亦即起始堆疊大小的最低點與已達堆疊大小上限之間的差異。
WallTime 是大部分最佳化作業的主要焦點，因此具有最高優先順序。不過，WallTime 會受到堆積分配量的影響 (特別是非非預期的)，因此堆積分配量是次要重點。除了最佳化 WallTime 之外，深層堆疊也會影響 Rust，而且可能也不適用於 C++，因此若使用這些語言 FIDL 對堆疊深度的貢獻，也應該一併追蹤。
基準套件
基準套件中的基準測試應簡單明瞭、清楚易懂。這些原則通常應有兩種類別：
- 有條理地建立綜合基準。這些類型應區隔特定的功能或功能組合，以便在繫結中指出假設的弱點。基準參數、元素數量 (根據其他基準數量) 應選擇，以便簡化比較作業。
綜合基準不應是任意組合的組合，如果它們值得最佳化，或對評估對實際成效的影響，將難以判斷其評估項目。
合成基準包括具有 16、32、256、1024 基元欄位、位元組向量、大小為 16、32、256、1024 和 uint8、uint64 的結構體。
- 根據實際 KPI 類型的基準測試。藉此衡量野生的效能。這對前瞻性最佳化和追蹤迴歸而言很實用。
迴歸基準的範例包括 fuchsia.io/File.ReadAt 回應，以及 fuchsia.posix.socket/DatagramSocket.SendMsg 要求。
GIDL 產生
產生 GIDL 時，應使用一組標準化基準產生每個繫結的基準程式碼。
所有基準的需求條件
Chromeperf 整合
所有基準測試都應匯出至 chromeperf，並使用 test_suite: fuchsia.fidl_microbenchmarks。
Builder / 編碼 / 解碼基準的 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/)。如果有一個基準 Perf 繫結架構執行個體，則該執行個體前面應加上繫結架構。 - 子基準 (例如大小) 會顯示在主要基準結束之後，由高到低排序。
- 子步驟會顯示在測量之前 (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 內的 mcpy 基準測試可用來存取 llcpp 類型，藉此測試正確大小的壓縮)。您應視為技術債，最終移至專用的基準和資料夾。