xxHash vs SHA-256: How Much Faster Is It?

Intro — what this post promises

xxHash is about 3-4.5x faster than SHA-256: hashing a 64 MiB buffer in Python 3.13.5, xxh128 reached about 6,695 MB/s and xxh3_64 about 5,998 MB/s, against about 1,468 MB/s for SHA-256 on a CPU with SHA-NI. They do different jobs, though: xxHash is a non-cryptographic checksum for hash tables and dedup fingerprints, so keep SHA-256 wherever integrity has to hold up against an attacker.

This is a hands-on lab with measured numbers:

1. One-shot digest throughput over a 64 MiB os.urandom buffer.
2. SHA-256, BLAKE2b (64- and 32-byte digests), BLAKE2s, SHA-1 (speed only), SHA3-256.
3. xxHash family: xxh64, xxh128, xxh3_64, xxh3_128.
4. Streaming with 1 MiB update() chunks for sha256 / blake2b / xxh64.

Related links:

• 01shoppercove.comzstd vs gzip vs lz4 compression localhost lab
• 02shoppercove.comopenssl TLS full vs resume localhost lab
• 03shoppercove.comfsync vs fdatasync localhost lab
• 04shoppercove.comWhy your average latency graph is lying (p50 / p95 / p99)
• 05shoppercove.comprocess vs thread pool GIL localhost lab

Lab honesty (1 Oct 2026 IST): Shared Linux lab box (8 cores, kernel 6.12, CPU flags include sha_ni). Python 3.13.5; OpenSSL 3.5.7; xxHash 0.8.3 via python3-xxhash. No Docker. Affiliates: 0. Throughput microbench — not a collision study, not HMAC.

Verdict up front: SHA-256 ~1468 MB/s beat BLAKE2b ~651 MB/s (~2.3×) on this box. xxh128 ~6695 MB/s led the checksum pack; xxh3_64 ~5998 MB/s.

What we compare (and what we do not)

Related links:

• 01shoppercove.comopenssl TLS full vs resume localhost lab

Lab topology

64 MiB os.urandom in RAM
One-shot: hashlib.<algo>(buf).digest() or xxhash.xxh*(buf).digest()
Stream: 1 MiB h.update slices, then digest()
Repeats: 7 (stream arms 5) after warmup; MB/s = 64 MiB / p50_s

Script: lab-evidence/35-sha256-vs-blake2-xxhash/results/run_lab.py.

Lead table — one-shot 64 MiB (p50)

SHA-256 / BLAKE2b ≈ 2.25× on this sha_ni host. That inverts older “BLAKE2 always wins on software” intuition — measure your CPU.

xxHash sits ~3–4.5× above SHA-256 here. Fine for hash maps / content-defined chunking when cryptography is not the requirement.

Stability×3 MB/s p50: sha256 1462 / 1477 / 1475; blake2b_64 654 / 641 / 644; xxh3_64 5756 / 6271 / 6472 (noisier — quote bands).

Related links:

• 01shoppercove.comWhy your average latency graph is lying (p50 / p95 / p99)

Streaming (1 MiB updates)

Chunked update() costs a bit vs one-shot for SHA-256 (~20% here) and stays in the same ballpark for xxh64. Streaming is what real file/hash pipelines do — still SHA-256 ≫ BLAKE2b on this box.

How to read these numbers

• Hardware accel matters. sha_ni in /proc/cpuinfo is the smoking gun for SHA-256’s lead.
• Digest size ≠ speed. blake2b_32 did not beat blake2b_64 meaningfully here.
• xxHash ≠ SHA-256. Different threat model; different MB/s class.
• SHA-1 looked fast (~1600 MB/s) — still do not use it for security.
• SHA3-256 (~429 MB/s) was the slow crypto hash in this set.

Related links:

• 01shoppercove.comzstd vs gzip vs lz4 compression localhost lab
• 02shoppercove.comnginx gzip on vs off localhost lab
• 03shoppercove.comasyncio vs threads IO concurrency lab

Pitfalls we hit (or avoided)

1. Assuming BLAKE2b > SHA-256 everywhere — false on this OpenSSL + SHA-NI box.
2. Calling xxHash a “faster SHA-256” — category error.
3. Omitting library versions — OpenSSL 3.5.7, xxHash 0.8.3, Python 3.13.5.
4. Tiny buffers — 64 MiB keeps fixed overhead small; still not a disk-bound hash.
5. Multi-thread CLI tools — this is single-buffer Python; openssl dgst -sha256 multi-buffer may differ.

One more honesty note: these MB/s figures are single-threaded Python calling into C/OpenSSL/xxHash. A Rust or C xxh3 loop, or openssl speed sha256, can print different absolute numbers. Keep the ranking and the sha_ni caveat as the portable lessons unless you re-bench the exact binary you ship.

Practical checklist

• For integrity/crypto: prefer SHA-256 or BLAKE2/SHA-3 with an explicit reason — benchmark the deploy CPU.
• For non-crypto speed (hash tables, dedup fingerprints): consider xxh3 / xxHash — and document “not a MAC.”
• Record OpenSSL / xxHash / CPU flags next to any MB/s claim.
• Prefer streaming APIs for large files; spot-check vs one-shot.
• Keep SHA-1 out of new security designs even when it wins a race.

Related links:

• 01shoppercove.comcosign SBOM CI sign/attest workflow
• 02shoppercove.comafter xz supply-chain checklist
• 03shoppercove.comcontext-switch pipe ping-pong localhost lab

Versions pinned for this run

• Python 3.13.5
• OpenSSL 3.5.7 (9 Jun 2026)
• xxHash library 0.8.3 (python3-xxhash 3.2.0-1+b5)
• CPU advertises sha_ni among other AVX-512 / AES flags

If your OpenSSL build is older or your CPU lacks SHA extensions, expect SHA-256 to drop relative to BLAKE2b — that is a feature of the hardware, not a reason to distrust this lab’s method.

Methodology footnote

All crypto digests went through Python hashlib (OpenSSL backend for SHA-*). xxHash used the xxhash module’s xxh64 / xxh128 / xxh3_* constructors. Wall time is time.perf_counter around the full digest call. Input was os.urandom so content compressibility is irrelevant (unlike the compression lab).

Relative speed (same 64 MiB buffer)

Using SHA-256 p50 as 1.0×:

If your fleet is mixed (some VMs without SHA-NI, some with), do not copy this table blindly — re-run the same script on a canary of each SKU. OpenSSL version bumps can also move SHA-256 without touching your app code.

Related links:

• 01shoppercove.comSO_REUSEPORT vs single listen lab
• 02shoppercove.comtcp nodelay vs nagle localhost lab

Verdict

On this sha_ni box, SHA-256 (~1468 MB/s) outran BLAKE2b (~651 MB/s) by ~2.3×, while xxh128 (~6695 MB/s) and xxh3_64 (~5998 MB/s) owned non-crypto checksum throughput. Quote CPU flags and library versions with any hash MB/s number — folklore does not ship.

Evidence path on the lab box: lab-evidence/35-sha256-vs-blake2-xxhash/results/. Affiliates: 0.

FAQ

Is xxHash faster than SHA-256?

Yes. On 64 MiB one-shot digests, xxh64 was 3.13x, xxh3_64 4.09x and xxh128 4.56x SHA-256's throughput. Streaming in 1 MiB chunks, xxh64 ran 4,970 MB/s vs 1,176 MB/s for SHA-256.

Can I use xxHash instead of SHA-256?

Only where cryptography isn't required, such as hash maps, dedup fingerprints or content-defined chunking. xxHash is not a MAC or a secure hash, so keep SHA-256 (or BLAKE2/SHA-3) for integrity and security.

Is BLAKE2 faster than SHA-256?

Not on this box. With SHA-NI hardware support and OpenSSL 3.5.7, SHA-256 (1,468 MB/s) beat BLAKE2b (651 MB/s) by about 2.3x. On CPUs without SHA extensions the ranking can flip.