工程趣聞 2026 年 10 月 13 日

2026-10-13 — Unreal 編輯器啟動:著色器雜湊由 SHA-1 換成 xxHash,耗時降八倍

primary=https://larstofus.com/2026/10/11/speeding-up-the-unreal-editor-by-not-using-unnecessarily-secure-hash-methods/ primary=https://github.com/EpicGames/UnrealEngine/pull/15237

Unreal 編輯器啟動:著色器雜湊由 SHA-1 換成 xxHash,耗時降八倍

Larst Of Us(Lars Thießen) · 2026-10-11

Unreal 編輯器啟動時用 SHA-1 替著色器原始碼算雜湊,如今換成引擎內本來就有的 xxHash,這一段的 CPU 時間從 12.90 秒掉到 1.59 秒。作者 Lars Thießen 在剖析(profiling)編輯器啟動流程時發現這個熱點,並向 Epic 提交了 PR #15237。

這件事的價值在於:雜湊在這裡只是拿來辨認「內容有沒有變」,用不到密碼學強度,卻付了密碼學雜湊的成本。

原本的問題

作者先看編輯器啟動時的 CPU 剖析。他一開始略過了名稱像 Compile Global Shader Map 的函式,因為它本來就要花數秒。放大之後才發現,它底下呼叫的一個函式在對著色器原始碼做 SHA-1。

被雜湊的內容是著色器原始碼,連註解與版權聲明都包含在內,資料量大,而且完全不敏感。SHA-1 是密碼學雜湊,文章指出它已被視為不安全、也偏慢。這個用途只需要一個快速、碰撞機率夠低的指紋,並不需要抗攻擊。

採用的方法

作者把 SHA-1 換成 xxHash。他提到還有更快的選擇,例如 Rapidhash 的 Unity 移植版,但最後選 xxHash,理由是引擎裡本來就有、也已經被測試過,不必引入新相依。

實作上比預期麻煩:所有儲存或傳遞這個雜湊的地方都得跟著改,需要動的位置比想像中多。附帶的結果是,儲存的雜湊從 20 位元組縮成 8 位元組。

舊做法新做法
演算法SHA-1xxHash(64 位元)
儲存大小20 位元組8 位元組
剖析中的函式FSHA1::UpdateFXxHash64Builder::Update

實際效果

測試用 Unreal 的範例專案 Electric Dreams:未修改與修改後的引擎各開編輯器 5 次,共 10 次,以 Superluminal 剖析。數字是所有執行緒的 CPU 時間加總,不是遊戲執行緒單獨的時間。

  • 原版引擎:FSHA1::Update 花了 12.90 秒
  • 修改版:FXxHash64Builder::Update 只花 1.59 秒

作者的結論是快了八倍。因為是跨執行緒加總,實際對啟動時間的影響,他估計約為這個差值除以核心數。文章沒有提供每次執行的明細,也沒有給整體啟動時間的百分比,這裡也不補。

審查中的調整與影響範圍

依文章所述,Epic 的審查者做了兩項調整:把 xxHash 包進新的結構 FShaderHash,這樣以後要換演算法,不必再改一大堆呼叫端;另外修掉了非編輯器建置的編譯錯誤,因為作者只測過編輯器建置。文章發表時,這個變更已被接受,但尚未合併進主分支,作者預期幾天內會合併。我們無法開啟該 PR 頁面(對外回傳 404),以上細節來自作者的文章。

對自己維護 Unreal 引擎分支的團隊來說,若著色器雜湊也走 SHA-1,可以對照這個 PR 檢查所有存放與比對雜湊的位置,因為改動不只一處。對其他引擎或建置系統的作者來說,值得查查:只用來做快取鍵、去重或變更偵測的雜湊,是否真的需要密碼學強度。如果不需要,換成非密碼學雜湊就能省下這段時間。

反過來,這個結論只適用於無對抗者的情境。若雜湊用來驗證來源或防止被刻意構造的碰撞,就不該這樣換;文章討論的是不敏感的著色器原始碼。

原始來源:Larst Of Us 原文、EpicGames/UnrealEngine PR #15237


End of article
0
Would love your thoughts, please comment.x
()
x