Swapping SHA1 for xxHash Cuts Unreal Editor Hash Time From 12.9 to 1.6 Seconds

A developer profiling Unreal Editor's launch found 12.90 seconds of CPU time going into one function, FSHA1::Update, and replaced it with a hash already shipped in the engine. The same work now takes 1.59 seconds, about 8.1 times less, according to a post published Oct. 11 on the larstofus.com blog.

The change is a pull request, #15237, on Epic Games' Unreal Engine repository. The post says Epic accepted it but had not merged it when the post went up.

What the profiler found

The author profiled editor startup with Superluminal, a sampling profiler, and went looking for work that other developers skip past. Under the "Compile Global Shader Map" step, a SHA1 call was hashing shader source code, including its comments and copyright notices.

SHA1 is a cryptographic hash that is flagged as broken in the xxHash project's own comparison table. Nothing about the data needs that property: nobody is attacking a shader file's checksum, and the hash only has to tell two versions of the file apart. The author replaced it with xxHash, specifically the 64-bit builder FXxHash64Builder::Update, which Unreal already contained.

A side effect is that every stored hash shrinks from 20 bytes to 8. The post says more code locations depended on the old width than the author expected.

The measured gain

Run	Function	CPU time, all threads
Unmodified editor	FSHA1::Update	12.90 s
With the pull request	FXxHash64Builder::Update	1.59 s

The test ran Unreal's "Electric Dreams" sample project, with five editor launches on each build. The post does not name the engine version.

The figure is summed across every thread, not wall-clock time on the game thread. The author notes that real startup savings are roughly that difference divided by the number of cores, so a machine with 16 cores would save under a second of launch time, not 11 seconds. The post gives no wall-clock launch figure.

Why xxHash is fast, and where it stops

The xxHash project publishes a benchmark of its own. On the Intel Core i7-9700K it uses as a reference system, running Ubuntu 20.04 with Clang 10 at -O3, the table lists these bandwidths:

1. XXH3 (AVX2)59.4 GB/s
2. XXH6419.4 GB/s
3. SHA10.8 GB/s
4. MD50.6 GB/s

Source: xxHash README benchmark table (Intel i7-9700K, Ubuntu 20.04, Clang 10 -O3), accessed 2026-10-13

The xxHash page describes XXH64 as the 64-bit variant using 64-bit arithmetic and recommends XXH3_64bits() for new code. These are the project's own numbers on one desktop chip and not a measurement of Unreal. They do explain the direction of the result: XXH64 moves 19.4 GB/s against 0.8 GB/s for SHA1, a 24-fold gap on raw throughput, while the editor test saw about 8 times, on a different machine and a different workload.

The page is blunt about the limits: "xxHash is not a cryptographic hash function," and it warns against signatures, password storage or anything that must resist an attacker. The author also says xxHash is not the fastest option available, only the one that was already in the codebase.

What to check before copying the idea

The post covers one sample project and was profiled in an editor build. The author broke non-editor builds, and Epic's side fixed them. An Epic reviewer also wrapped the hash in a new FShaderHash struct so the algorithm can be changed later without another sweep through the code.

That sweep is the real cost. Anyone swapping a hash in a large codebase has to find every place a digest is stored, compared or sized, which is what turned a one-line idea into a pull request. Throughput claims travel badly between machines, a point that also applies to the fastsimdjson Python parser numbers and the Postgres NVMe versus gp3 benchmark covered earlier.

The open item is the merge. Until pull request #15237 lands in an Unreal release, the 12.9 seconds stays in every editor launch.