通过……不使用不必要的安全哈希方法来加速 Unreal 编辑器

# 提升 Unreal 编辑器速度——通过不使用不必要的安全哈希方法 Source: https://larstofus.com/2026/10/11/speeding-up-the-unreal-editor-by-not-using-unnecessarily-secure-hash-methods/ 在寻找软件优化方案时，一个很好的技巧是远离那些很可能已经被充分优化的区域，转而关注那些可能被忽略的地方——要么因为它们太冷门，要么因为在常规性能分析中根本不会出现。这个策略过去效果很好，比如我之前对工具提示创建的优化（https://larstofus.com/2025/09/02/speeding-up-the-unreal-editor-launch-by-not-spawning-38000-tooltips/），以及编辑器本地化文件加载的优化（https://larstofus.com/2025/09/02/speeding-up-the-unreal-editor-launch-by-not-spawning-38000-tooltips/）。 所以当（再次）对编辑器启动进行性能分析时，这就是为什么我基本上会跳过所有包含 "Shader Compilation" 或 "Shader Source" 等关键词的函数。着色器编译是一个出了名的漫长而复杂的过程，我非常确定 Epic 里那些非常聪明的人已经在这些区域花费了大量时间进行优化。这就是为什么，例如，我会跳过 "Compile Global Shader Map" 这个函数，尽管它的运行时间通常长达数秒： 至少在我以异常高的缩放级别跳过它并看到它调用的其中一个函数之前，这都是正确的： 我当然不是哈希算法方面的专家，但 SHA1 是连我也知道的（极少数）哈希算法之一。看到这种哈希算法被用来对着色器进行哈希处理，不知怎么让我觉得不太对劲。因为 SHA1（https://en.wikipedia.org/wiki/SHA-1）曾经是一个密码学安全的哈希算法，最初由 NSA 开发（没错，就是那个 NSA）。虽然它多年前在密码学上已被破解，实际上不应该再用于敏感信息，但这个出身意味着它——客气点说——速度并不快。在这个语境下"不快"是什么意思？可以看看 Aras Pranckevičius 几年前做的这个常见哈希算法对比测试（https://aras-p.info/blog/2016/08/09/More-Hash-Function-Tests/）（实际上是 10 年前——我老了）。SHA1 甚至没有被作为真正的竞争者，正如文章开头所指出的，它只是被包括进来"以展示性能差异"。真惨。这尤其令人恼火，因为被哈希的数据就是着色器源代码，包括所有注释和版权声明： 这意味着我们既需要对大量数据进行哈希（源文件可能相当大），而且没有必要使用密码学安全哈希来处理，因为这些根本不是敏感数据。 因此，使用一个快速而非密码学安全的哈希算法应该是一个轻松的胜利，对吧？而所引用的那篇文章已经提出了一个很好的替代方案，我甚至在 Unreal 的代码库中找到了一个现成的实现：xxHash。 在有人提问之前先说明：xxHash 不一定是最快的哈希。其他可能更快的哈希确实存在（https://aras-p.info/blog/2026/03/07/Rapidhash-Unity-port/），但目前，使用一个已经在我们所使用的引擎中经过测试的更快哈希是更直接的选择。更改所使用的哈希并不太复杂，尽管我需要改动的代码位置比预期的要多，因为所有存储或传递生成哈希的位置都需要同步更新。这个更改的一个好的副作用是存储的哈希比之前小了一些（8 字节而不是 20 字节）。但当然，我做这个更改的目的不在于内存，而在于 CPU 时间。为了测试，我用修改前后的引擎各 5 次在编辑器中打开了 Unreal 自带的示例项目 Electric Dreams（https://www.fab.com/listings/d79688f5-29be-4fb2-a650-2d4a813f5306?lang=en），总共 10 次运行。性能分析使用 Superluminal（https://superluminal.eu/）完成。 为了方便理解下面的数字，我要说明的是，我主要讨论的是所有线程的总 CPU 时间，而不仅仅是游戏线程上的时间。这样做不是为了人为地夸大数字，而是为了让数字更一致、更容易比较。对编辑器启动时间的实际影响（非常粗略地）是测量时间除以核心数。 在原版引擎中，有惊人的 12.90 秒花在了 FSHA1::Update 上。在使用 xxHash 的修改版本中，这个时间缩小到仅 1.59 秒花在了 FXxHash64Builder::Update 上。快了八倍！任务完成。 通常，这篇文章现在会以一个指向 pull request 的链接结尾，这样任何对这个更改感兴趣的人都可以在等待和期望 Epic 的某人看到该 pull request 并将其合并到主分支的同时，将其集成到自己的引擎版本中。而这次我有更好的消息：这个更改已经被接受了！（不过尚未合并，似乎还需要几天时间）我在写这篇文章前几天提交了 pull request（https://github.com/EpicGames/UnrealEngine/pull/15237），而这几天已经足够让 Epic 的某人不仅审查了我的更改，还对其进行了完善。那么让我们来看看对我的提议所做的部分修改：一个我没想到的非常聪明的处理是将 xxHash 包装到另一个结构体 FShaderHash 中。这目前不会改变行为，但如果未来需要使用更快的哈希算法，将更容易再次更换哈希算法，而无需在许多不同位置修改代码。修复了非编辑器构建的编译错误：那是我的疏忽。我只在编辑器构建中测试了我的更改，主要是因为我的原始性能分析也是在编辑器中完成的。未来我可能需要将非编辑器构建加入我在提交 pull request 前需要执行的检查清单中。就是这样了。如果你喜欢这篇文章并希望未来阅读更多关于游戏优化的内容，可以考虑在 BlueSky（https://bsky.app/profile/larstofus.bsky.social）、Mastodon（https://mastodon.gamedev.place/@LarsThiessen）或 Linkedin（http://www.linkedin.com/in/larstofus）上关注我，我在那里发布我所有的文章。或者直接在文章下方订阅我的博客。