hashcodecs 1.3.0__tar.gz → 1.4.1__tar.gz

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/.gitignore

@@ -10,6 +10,9 @@ site/
 .venv*/
 .coverage
 coverage.xml
+*.profraw
+*.lcov
+*.log
 
 # These are backup files generated by rustfmt
 **/*.rs.bk

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/BENCHMARK.md

@@ -9,6 +9,9 @@ Build the Python wheel with CPython 3.12 and the full C API. Keep competitor val
 Use `uv run --python 3.12 --no-project python benchmarks/render_charts.py` to render the charts. Read exact values in
 [docs/benchmarks/results.csv](docs/benchmarks/results.csv).
 
+Python values use CPython 3.12.10 and report the median of 15 samples lasting at least 0.2 seconds each, with one
+logical CPU pinned. Focused runs refresh only the affected series; other values retain their previous measurements.
+
 ## Timing Controls
 
 Every Python benchmark accepts `--samples` (default: 15) and `--minimum-sample-seconds` (default: 0.2). Their
@@ -27,6 +30,43 @@ GIL-detachment cutoffs. The `--thread-scaling` mode measures aggregate throughpu
 it does not pin the process to one logical CPU. Use `--buffer-inputs` to compare 64-byte and 4 KiB XXH3-64 calls
 across bytes, full and sliced memoryviews, writable and non-contiguous views, and `array('B')`.
 
+## Rust MurmurHash3 x64 Dispatch
+
+Use scalar below 512 bytes of full blocks, then AVX2 when available. The SSE4.1 fallback starts at 512 bytes
+and retains its 8 MiB upper limit. Incremental updates apply these thresholds to each batch of full blocks.
+
+Forced-backend measurements with complete finalization on the Core Ultra 7 265K put scalar and AVX2 near parity
+at 384 bytes (39.99 and 40.20 ns/hash), with AVX2 ahead at 512 bytes (53.98 and 52.76 ns/hash). Use 512 bytes as
+a crossover candidate for this host. The shared minimum also avoids the measured SSE4.1 overhead on small inputs;
+it does not establish an SSE4.1 crossover or an optimum across Intel and AMD CPUs.
+
+The following public Rust API measurements include runtime dispatch and finalization. On 2026-09-13, we collected
+50 Criterion samples per case with one logical CPU pinned, a 300 ms warmup, and a 1 s measurement target. These
+values report Criterion's mean estimate with seed 42; they are separate from the forced-backend measurements.
+
+| Input | ns/hash |
+| --- | ---: |
+| 15 B | 5.32 |
+| 16 B | 5.47 |
+| 31 B | 5.89 |
+| 32 B | 6.03 |
+| 64 B | 7.80 |
+| 255 B | 24.42 |
+| 256 B | 25.04 |
+| 384 B | 37.93 |
+| 511 B | 50.35 |
+| 512 B | 49.79 |
+| 513 B | 50.43 |
+| 1 KiB | 96.89 |
+
+We refreshed the x64 hashcodecs series in the Rust MurmurHash3 throughput chart on the same date, retaining the
+x86 and competitor measurements from the previous comparison run.
+
+```sh
+cargo bench --manifest-path benches/Cargo.toml --bench crossover -- murmur_x64_128_crossover
+cargo bench --manifest-path benches/Cargo.toml --bench murmur3 -- x64_128/hashcodecs
+```
+
 ## XXH3
 
 For the Rust comparison, link hashcodecs with xxHash 0.8.3 through `xxhash-c-sys`. Build the C baseline with AVX2.
@@ -34,15 +74,85 @@ For Python, run the upstream `xxhash` extension beside hashcodecs. Pass 32 equal
 The Rust remainder cases pass two or three equal-size long inputs. Run Python remainder cases with
 `python benchmarks/python_xxhash.py --batch-counts 2 3`.
 
-The Rust mixed benchmarks use `[1024, 1024, 4096, 4096]`, `[240, 240, 241, 241]`, and the reverse boundary order.
-The 1024/4096 case measures adjacent two-item long runs. The 240/241 cases measure both orders across the
-short/long dispatch boundary.
+To measure a branch against its parent, build both extensions with the same Python and Rust toolchains, then run:
+
+```sh
+uv run --frozen --no-sync python benchmarks/compare_xxh3_batches.py path/to/parent/_hashcodecs.pyd path/to/branch/_hashcodecs.pyd
+```
+
+Use the corresponding `.so` paths on Linux or macOS. The comparison loads both builds into one interpreter, pins
+one CPU, and alternates their timing order across 15 samples. It checks matching digests and covers bytes,
+bytearrays, and writable memoryviews. Use `--batch-counts 2 9 32 33 --sizes 64` to inspect small batches and the
+32-result stack boundary. Positive `change_percent` values mean higher branch throughput.
+
+The [32-item parent comparison](docs/benchmarks/xxh3-batch-parent-comparison.csv) records CPython 3.12.10 results
+against parent commit `f17ab86`, measured on 2026-09-05. These paired measurements also cover the 256 KiB
+GIL-detachment threshold and 1 MiB items. The Python XXH3 batch panels report CPython 3.12.10 measurements
+from 2026-09-13, using 15 samples of at least 0.2 seconds; one-shot and upstream values retain their prior measurements.
+
+Across the 30 paired 32-item cases, branch throughput ranges from 2.59% lower to 2.70% higher than the parent.
+The [stack-boundary comparison](docs/benchmarks/xxh3-batch-boundary-comparison.csv) covers counts 2 and 33 with
+64-byte items: two-item bytearray batches lose 5.40–6.05%, and 33-item bytes batches lose 6.06–7.05%. These
+measurements show residual overhead for some small-input batches; they do not establish zero regression.
+
+### Packed-batch detachment
+
+XXH3 batches release the GIL at 1 MiB of total input or 16,384 items, provided the input buffers permit detachment.
+The item limit accounts for per-item hashing and output work, including empty inputs. One-shot XXH3 keeps its
+256 KiB threshold. Mutable inputs retain their existing synchronization rules.
+
+The detached packed path retains input owners, borrows 64 inputs at a time on the stack, and stages results until
+it reacquires the GIL and rechecks the output size. This removes one allocation and 16 bytes of temporary input
+descriptors per item on 64-bit hosts. Little-endian hosts copy staged results in one operation.
+
+The [candidate measurements](docs/benchmarks/xxh3-packed-candidates.csv) compare 256 KiB, 512 KiB, and 1 MiB
+byte thresholds with the same allocation reduction and 16,384-item limit. Each exploratory value uses five
+samples of at least 0.03 seconds. The 1 MiB policy keeps both 4,096- and 8,192-item batches of 64-byte inputs on
+the direct-output path. This trades longer GIL holds for lower latency; it does not establish an optimal threshold
+for other processors or contended workloads.
+
+The [selected-policy measurements](docs/benchmarks/xxh3-packed-thresholds.csv) use CPython 3.15.0b4 on the
+Intel Core Ultra 7 265K, with one logical CPU pinned, independent input allocations, and 15 samples of at least
+0.2 seconds each, measured on 2026-09-13. They cover both digest widths and item sizes of 64 bytes, 1 KiB, and 64 KiB.
+For 64-byte inputs:
+
+| Items | XXH3-64 packed latency | XXH3-128 packed latency |
+| ---: | ---: | ---: |
+| 4,095 | 13.92 µs | 27.29 µs |
+| 4,096 | 14.48 µs | 27.33 µs |
+| 4,097 | 13.95 µs | 27.44 µs |
+| 8,191 | 28.95 µs | 54.72 µs |
+| 8,192 | 29.14 µs | 54.61 µs |
+| 8,193 | 29.46 µs | 54.57 µs |
+| 16,383 | 58.49 µs | 109.12 µs |
+| 16,384 | 92.78 µs | 144.04 µs |
+| 16,385 | 94.52 µs | 145.62 µs |
+
+A discontinuity remains at the new detachment boundary because retaining owners and staging output still cost work.
+The longest measured attached call near these boundaries takes about 109 microseconds. This is a latency
+measurement on this host, not a bound on thread waiting time; the tests also verify GIL progress for large inputs
+and for 16,384-item batches of empty, one-byte, and 64-byte inputs.
+
+```sh
+uv run --frozen --no-sync python benchmarks/python_xxhash_thresholds.py --output docs/benchmarks/xxh3-packed-thresholds.csv
+uv run --frozen --no-sync python benchmarks/python_xxhash.py --batches-only --hashcodecs-only
+```
+
+`--thresholds-kib` selects benchmark input sizes around each candidate; it does not change the extension's
+compiled policy. To compare candidates, rebuild the wheel after changing `BATCH_DETACH_BYTES` in
+`src/bindings/xxhash/batch.rs`.
+
+The Rust mixed benchmarks use `[1024, 1024, 4096, 4096]`, `[257, 258, 259, 260]`, `[240, 240, 241, 241]`, and the
+reverse boundary order. The 1024/4096 case measures adjacent two-item long runs. The 257–260 case measures a
+four-item run with one shared stripe count and distinct final stripes. The 240/241 cases measure both orders across
+the short/long dispatch boundary.
 
 Use the focused one-shot run to cover the AVX2 four-chain boundaries:
 
 ```sh
 cargo bench --manifest-path benches/Cargo.toml --bench xxhash -- "xxh3_(64|128)/(240|241|512|768|1024|1536|2048|4096)/hashcodecs"
 cargo bench --manifest-path benches/Cargo.toml --bench xxhash -- "xxh3_batch/mixed/.*/hashcodecs_(64|128)"
+cargo bench --manifest-path benches/Cargo.toml --bench xxhash -- "xxh3_prepared"
 ```
 
 [![Rust XXH3 throughput](docs/benchmarks/xxh3-rust.svg)](docs/benchmarks/xxh3-rust.svg)
@@ -62,14 +172,23 @@ Pass one reusable `bytearray` to each `*_into` call.
 Run `python benchmarks/python_base64.py --lenient`. The MIME cases insert CRLF after each 76-character line. The
 noisy cases insert `!` at the same boundaries. Both cases measure returned bytes and reusable output buffers.
 
+Run `uv run --no-project --python 3.12 python benchmarks/python_base64.py --custom-lenient` to measure clean and noisy
+inputs with `@#` altchars. For a 1 MiB decoded payload, the custom clean case reaches 3.44 GiB/s with returned bytes
+and 13.05 GiB/s with a reusable output buffer. The decoder translates complete symbol runs in a 4 KiB staging buffer
+for SIMD decoding and handles padding and ignored characters through the lenient state machine.
+
 [![Lenient Python Base64 throughput](docs/benchmarks/base64-python-lenient.svg)](docs/benchmarks/base64-python-lenient.svg)
 
+## Wrapped Python Base64
+
+Run `python benchmarks/python_base64.py --wrapped` with CPython 3.15 or newer. The benchmark inserts newlines after
+76 output characters and measures returned bytes and a reusable `bytearray`.
+
 ## Python Memoryview Inputs
 
 Use `--memoryview-input` for full immutable views and `--sliced-memoryview-input` for equal-length contiguous views
-with a nonzero starting offset. Full views can recover their exact immutable owner at detachment sizes; slices cover
-offset-buffer handling, which borrows under the GIL and stabilizes the input in free-threaded builds. The encoded data
-remains identical.
+with a nonzero starting offset. At detachment sizes, both retain the immutable bytes owner without copying the input.
+Callback-capable decode arguments keep their required snapshots and conversion order. Both modes use identical data.
 
 [![Python Base64 memoryview inputs](docs/benchmarks/base64-python-memoryview.svg)](docs/benchmarks/base64-python-memoryview.svg)
 

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/CHANGELOG.md

@@ -4,6 +4,53 @@ This file records notable user-facing changes to `hashcodecs`. Version 1.0.0 sta
 
 ## [Unreleased]
 
+## [1.4.1] - 2026-09-13
+
+### What's Changed
+* fix: match CPython Base64 and XXH3 buffer semantics by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/114
+* fix: preserve Base64 callback buffer semantics by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/115
+* fix: preserve CPython Base64 observable behavior by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/116
+* fix: resolve repository type diagnostics by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/117
+* fix: release Base64 input buffers before writing output by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/118
+* refactor: centralize buffer callback policy and clarify finalizers by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/119
+* fix: accelerate custom-alphabet lenient Base64 decoding by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/120
+* fix: reduce XXH3 packed batch detachment overhead by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/121
+* fix: delay MurmurHash3 x64 SIMD dispatch until 512 bytes by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/122
+* fix: restore Python buffer and batch throughput by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/123
+* fix: typo in the performance viz image by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/124
+
+
+**Full Changelog**: https://github.com/kozistr/hashcodecs-rs/compare/v1.4.0...v1.4.1
+
+## [1.4.0] - 2026-09-10
+
+### What's Changed
+* refactor: flatten internal module layout by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/91
+* refactor: prepare Base64 decoder policies once by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/92
+* refactor: consolidate binding and dispatch cleanup by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/93
+* refactor: simplify project module layout by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/94
+* refactor: prepare codec policies and unify bindings by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/95
+* refactor: accelerate Base64 codec hot paths by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/96
+* fix: protect XXH3 batches from GC reentrancy by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/97
+* refactor: unify Base64 decode execution by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/98
+* refactor: flatten Base64 binding ownership by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/99
+* refactor: improve XXH3 loads and internal naming by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/100
+* refactor: reduce Base64 decoder setup and retry costs by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/101
+* fix: preserve Base64 decode boundaries and restore ARM coverage by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/102
+* refactor: keep XXH3 AVX2 tail chains in registers by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/103
+* refactor: store AVX2 Base64 vectors in smaller groups by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/104
+* fix: reduce Python overhead and align canonical decoding by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/106
+* refactor: reduce cached AVX2 encoder setup by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/107
+* feat: optimize XXH3 seeded and batch hashing by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/108
+* Optimize AVX2 Base64 decoding by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/109
+* refactor: optimize Python batch orchestration by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/110
+* feat: optimize XXH3 batches and wrapped Base64 by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/111
+* Fuse Base64 SIMD lookup paths and Murmur3 hex output by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/112
+* fix: preserve custom alphabets and batch typing by @kozistr in https://github.com/kozistr/hashcodecs-rs/pull/113
+
+
+**Full Changelog**: https://github.com/kozistr/hashcodecs-rs/compare/v1.3.0...v1.4.0
+
 ## [1.3.0] - 2026-09-04
 
 ### What's Changed
@@ -164,7 +211,9 @@ This file records notable user-facing changes to `hashcodecs`. Version 1.0.0 sta
 - Initial Python and Rust APIs for Base64 and MurmurHash3.
 - Runtime SIMD dispatch and platform-specific CPython wheels.
 
-[Unreleased]: https://github.com/kozistr/hashcodecs-rs/compare/v1.3.0...HEAD
+[Unreleased]: https://github.com/kozistr/hashcodecs-rs/compare/v1.4.1...HEAD
+[1.4.1]: https://github.com/kozistr/hashcodecs-rs/compare/v1.4.0...v1.4.1
+[1.4.0]: https://github.com/kozistr/hashcodecs-rs/compare/v1.3.0...v1.4.0
 [1.3.0]: https://github.com/kozistr/hashcodecs-rs/compare/v1.2.1...v1.3.0
 [1.2.1]: https://github.com/kozistr/hashcodecs-rs/compare/v1.2.0...v1.2.1
 [1.2.0]: https://github.com/kozistr/hashcodecs-rs/compare/v1.1.0...v1.2.0

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/CITATION.cff

@@ -5,8 +5,8 @@ authors:
     given-names: Hyeongchan
     orcid: https://orcid.org/0000-0002-1729-0580
 title: "hashcodecs: SIMD-accelerated Base64, MurmurHash3, and XXH3 for Python and Rust"
-version: 1.3.0
-date-released: 2026-09-04
+version: 1.4.1
+date-released: 2026-09-13
 license: "MIT OR Apache-2.0"
 repository-code: "https://github.com/kozistr/hashcodecs-rs"
 url: "https://github.com/kozistr/hashcodecs-rs"

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/Cargo.lock

@@ -194,7 +194,7 @@ dependencies = [
 
 [[package]]
 name = "hashcodecs"
-version = "1.3.0"
+version = "1.4.1"
 dependencies = [
  "base64",
  "memchr",

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "hashcodecs"
-version = "1.3.0"
+version = "1.4.1"
 edition = "2024"
 rust-version = "1.89"
 autobenches = false
@@ -11,6 +11,7 @@ keywords = ["base64", "simd", "murmur3", "xxhash", "python"]
 categories = ["encoding", "algorithms"]
 readme = "README.md"
 include = [
+    "/generated/**",
     "/src/**",
     "/benches/**",
     "/tests/sanitizers.rs",

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: hashcodecs
-Version: 1.3.0
+Version: 1.4.1
 Summary: SIMD-accelerated Base64, MurmurHash3, and xxHash codecs
 Project-URL: Documentation, https://hashcodecs-rs.readthedocs.io/
 Project-URL: Repository, https://github.com/kozistr/hashcodecs-rs
@@ -56,7 +56,7 @@ Move byte-heavy work into Rust without changing your Python inputs. `hashcodecs`
 
 - Base64 encode and decode with standard, URL-safe, padded, unpadded, wrapped, and canonical modes.
 - MurmurHash3 x86-32, x86-128, and x64-128 with one-shot and incremental APIs.
-- Bit-for-bit compatible XXH3-64 and XXH3-128 with allocating and allocation-free native batch APIs.
+- Bit-for-bit compatible XXH3-64 and XXH3-128 with prepared seeds and allocating and allocation-free native batch APIs.
 - Caller-managed `*_into` outputs for allocation-sensitive workloads.
 - Runtime dispatch across AVX-512, AVX2, SSE4.1, SSSE3, NEON, and scalar implementations where applicable.
 - Direct CPython buffer handling for `bytes`, `bytearray`, and `memoryview` inputs.
@@ -147,7 +147,18 @@ assert_eq!(
     0x2d06_8005_38d3_94c2
 );
 
+let seeded_input = vec![7; 1024];
+let prepared = hashcodecs::xxhash::PreparedXxh3::new(42);
+assert_eq!(
+    prepared.hash_64(&seeded_input),
+    hashcodecs::xxhash::xxh3_64(&seeded_input, 42)
+);
+
 let inputs: &[&[u8]] = &[b"hello", b"world"];
+assert_eq!(
+    prepared.hash_64_batch(inputs),
+    hashcodecs::xxhash::xxh3_64_batch(inputs, 42)
+);
 let mut hashes = [0_u64; 2];
 let mut index = 0;
 hashcodecs::xxhash::xxh3_64_batch_for_each(inputs, 0, |hash| {
@@ -242,10 +253,7 @@ cargo bench --manifest-path benches/Cargo.toml --bench xxhash
 
 ## Performance snapshot
 
-In the full 2026-09-02 hashcodecs-only run on the benchmark host, `hashcodecs.xxh3_64` processes a 1 MiB input at
-90.07 GiB/s. With 256 B items in batches of 64, the Base64 batch API reaches 11.84 GiB/s for encode and 6.23 GiB/s for
-decode. The run pins one logical CPU and uses 15 samples with a 0.2-second minimum per sample. Read the
-[benchmark details](BENCHMARK.md) and [raw comparison results](docs/benchmarks/results.csv).
+On the benchmark host, `hashcodecs.xxh3_64` processes a 1 MiB input at 91.62 GiB/s. The Base64 batch API reaches 11.56 GiB/s for encode and 8.28 GiB/s for decode with 256 B items in batches of 64. Each run pins one logical CPU and uses 15 samples with a 0.2-second minimum per sample. Read the [benchmark details](BENCHMARK.md) and [raw comparison results](docs/benchmarks/results.csv).
 
 ## Development
 
@@ -258,14 +266,12 @@ uv build
 Run the primary local checks:
 
 ```sh
-cargo fmt --check
-cargo clippy --all-targets --features python -- -D warnings
-cargo test --features python
-uv run --frozen --no-sync ruff check . --no-cache
-uv run --frozen --no-sync ruff format --check .
-uv run --frozen --no-sync pytest tests --cov=hashcodecs --cov-branch --cov-fail-under=100
+just check
 ```
 
+`just check` builds and reinstalls the current wheel before running Python tests. Run `just full-check` before
+committing to also check release builds, Rust core coverage, and the extracted source distribution.
+
 Optimized paths are also checked with differential fuzzing, Kani, strict-provenance Miri, AddressSanitizer, and
 MemorySanitizer in CI.
 

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/README.md

@@ -25,7 +25,7 @@ Move byte-heavy work into Rust without changing your Python inputs. `hashcodecs`
 
 - Base64 encode and decode with standard, URL-safe, padded, unpadded, wrapped, and canonical modes.
 - MurmurHash3 x86-32, x86-128, and x64-128 with one-shot and incremental APIs.
-- Bit-for-bit compatible XXH3-64 and XXH3-128 with allocating and allocation-free native batch APIs.
+- Bit-for-bit compatible XXH3-64 and XXH3-128 with prepared seeds and allocating and allocation-free native batch APIs.
 - Caller-managed `*_into` outputs for allocation-sensitive workloads.
 - Runtime dispatch across AVX-512, AVX2, SSE4.1, SSSE3, NEON, and scalar implementations where applicable.
 - Direct CPython buffer handling for `bytes`, `bytearray`, and `memoryview` inputs.
@@ -116,7 +116,18 @@ assert_eq!(
     0x2d06_8005_38d3_94c2
 );
 
+let seeded_input = vec![7; 1024];
+let prepared = hashcodecs::xxhash::PreparedXxh3::new(42);
+assert_eq!(
+    prepared.hash_64(&seeded_input),
+    hashcodecs::xxhash::xxh3_64(&seeded_input, 42)
+);
+
 let inputs: &[&[u8]] = &[b"hello", b"world"];
+assert_eq!(
+    prepared.hash_64_batch(inputs),
+    hashcodecs::xxhash::xxh3_64_batch(inputs, 42)
+);
 let mut hashes = [0_u64; 2];
 let mut index = 0;
 hashcodecs::xxhash::xxh3_64_batch_for_each(inputs, 0, |hash| {
@@ -211,10 +222,7 @@ cargo bench --manifest-path benches/Cargo.toml --bench xxhash
 
 ## Performance snapshot
 
-In the full 2026-09-02 hashcodecs-only run on the benchmark host, `hashcodecs.xxh3_64` processes a 1 MiB input at
-90.07 GiB/s. With 256 B items in batches of 64, the Base64 batch API reaches 11.84 GiB/s for encode and 6.23 GiB/s for
-decode. The run pins one logical CPU and uses 15 samples with a 0.2-second minimum per sample. Read the
-[benchmark details](BENCHMARK.md) and [raw comparison results](docs/benchmarks/results.csv).
+On the benchmark host, `hashcodecs.xxh3_64` processes a 1 MiB input at 91.62 GiB/s. The Base64 batch API reaches 11.56 GiB/s for encode and 8.28 GiB/s for decode with 256 B items in batches of 64. Each run pins one logical CPU and uses 15 samples with a 0.2-second minimum per sample. Read the [benchmark details](BENCHMARK.md) and [raw comparison results](docs/benchmarks/results.csv).
 
 ## Development
 
@@ -227,14 +235,12 @@ uv build
 Run the primary local checks:
 
 ```sh
-cargo fmt --check
-cargo clippy --all-targets --features python -- -D warnings
-cargo test --features python
-uv run --frozen --no-sync ruff check . --no-cache
-uv run --frozen --no-sync ruff format --check .
-uv run --frozen --no-sync pytest tests --cov=hashcodecs --cov-branch --cov-fail-under=100
+just check
 ```
 
+`just check` builds and reinstalls the current wheel before running Python tests. Run `just full-check` before
+committing to also check release builds, Rust core coverage, and the extracted source distribution.
+
 Optimized paths are also checked with differential fuzzing, Kani, strict-provenance Miri, AddressSanitizer, and
 MemorySanitizer in CI.
 

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/SAFETY.md

@@ -17,6 +17,23 @@ The checks are deliberately complementary:
   exact Base64 buffers, incremental MurmurHash3 states, and XXH3 batch kernels.
 - libFuzzer runs under sanitizers. Base64 is compared with `base64` 0.23.1,
   MurmurHash3 with `murmur3` 0.5, and XXH3 with `xxhash-rust` 0.8.18.
+  XXH3 cases use independent equal-length and heterogeneous buffers, with
+  distinct lane contents and batch counts through nine to cover SIMD groups and tails.
+
+The Python XXH3 batch bindings finish all input reads before allocating Python
+result containers: a GC finalizer can clear the input list or resize a bytearray
+even while the GIL is held. Up to 32 native results fit on the stack; larger
+batches use a fallible vector. Large immutable inputs keep their owners across
+GIL detachment. Subprocess tests on CPython 3.10/3.11 trigger finalizers during
+allocation and reuse freed storage, covering both sides of the stack boundary.
+
+Packed XXH3 batches retain immutable input owners before detaching, then borrow
+64 inputs at a time into stack storage. They stage hashes in native memory;
+after reattaching, they recheck the destination length before copying results.
+The little-endian bulk copy relies on the padding-free layout contract of the
+private `PackedDigest` trait. Big-endian hosts serialize each word. Tests clear
+the source list and shrink the output from another Python thread before hashing
+the retained inputs and checking the output size again.
 
 Run the same checks locally on Linux:
 

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/benches/crossover.rs

@@ -8,6 +8,7 @@ mod support;
 const BASE64_ENCODE_SIZES: [usize; 10] = [15, 16, 31, 32, 47, 48, 51, 52, 103, 104];
 const BASE64_DECODE_SIZES: [usize; 8] = [12, 16, 28, 32, 60, 64, 124, 128];
 const MURMUR_SIZES: [usize; 6] = [15, 16, 31, 32, 255, 256];
+const MURMUR_X64_SIZES: [usize; 12] = [15, 16, 31, 32, 64, 255, 256, 384, 511, 512, 513, 1024];
 
 fn data(size: usize) -> Vec<u8> {
     (0..size)
@@ -41,9 +42,9 @@ fn base64_decode(c: &mut Criterion) {
 }
 
 macro_rules! murmur_group {
-    ($criterion:expr, $name:literal, $function:path) => {{
+    ($criterion:expr, $name:literal, $function:path, $sizes:expr) => {{
         let mut group = $criterion.benchmark_group($name);
-        for size in MURMUR_SIZES {
+        for size in $sizes {
             let input = data(size);
             group.throughput(Throughput::Bytes(size as u64));
             group.bench_with_input(BenchmarkId::from_parameter(size), &input, |bench, input| {
@@ -58,17 +59,20 @@ fn murmur3(c: &mut Criterion) {
     murmur_group!(
         c,
         "murmur_x86_32_crossover",
-        hashcodecs::murmur3::murmur3_x86_32
+        hashcodecs::murmur3::murmur3_x86_32,
+        MURMUR_SIZES
     );
     murmur_group!(
         c,
         "murmur_x86_128_crossover",
-        hashcodecs::murmur3::murmur3_x86_128
+        hashcodecs::murmur3::murmur3_x86_128,
+        MURMUR_SIZES
     );
     murmur_group!(
         c,
         "murmur_x64_128_crossover",
-        hashcodecs::murmur3::murmur3_x64_128
+        hashcodecs::murmur3::murmur3_x64_128,
+        MURMUR_X64_SIZES
     );
 }
 

{hashcodecs-1.3.0 → hashcodecs-1.4.1}/benches/xxhash.rs

@@ -6,9 +6,10 @@ use criterion::{BenchmarkId, Criterion, Throughput, criterion_group, criterion_m
 
 mod support;
 
-const SIZES: [usize; 15] = [
+const SIZES: [usize; 16] = [
     16,
     17,
+    32,
     64,
     128,
     129,
@@ -23,8 +24,9 @@ const SIZES: [usize; 15] = [
     1024 * 1024,
     8 * 1024 * 1024,
 ];
-const MIXED_BATCHES: [(&str, [usize; 4]); 3] = [
+const MIXED_BATCHES: [(&str, [usize; 4]); 4] = [
     ("two_long_runs", [1024, 1024, 4 * 1024, 4 * 1024]),
+    ("nearby_long_lengths", [257, 258, 259, 260]),
     ("short_then_long_boundary", [240, 240, 241, 241]),
     ("long_then_short_boundary", [241, 241, 240, 240]),
 ];
@@ -140,7 +142,7 @@ fn benchmark_batch(c: &mut Criterion, group_name: &str, owned: &[Vec<u8>]) {
 
 fn batch(c: &mut Criterion) {
     for items in [2, 3, 32] {
-        for size in [64, 1024, 4 * 1024, 1024 * 1024] {
+        for size in [64, 241, 1024, 4 * 1024, 1024 * 1024] {
             let owned = (0..items)
                 .map(|index| data(size, index as u8))
                 .collect::<Vec<_>>();
@@ -158,10 +160,79 @@ fn batch(c: &mut Criterion) {
     }
 }
 
+fn prepared_seed(c: &mut Criterion) {
+    for size in [241, 1024] {
+        let input = data(size, 17);
+        let prepared = hashcodecs::xxhash::PreparedXxh3::new(42);
+        assert_eq!(
+            prepared.hash_64(&input),
+            hashcodecs::xxhash::xxh3_64(&input, 42)
+        );
+        assert_eq!(
+            prepared.hash_128(&input),
+            hashcodecs::xxhash::xxh3_128(&input, 42)
+        );
+
+        let mut group = c.benchmark_group(format!("xxh3_prepared/{size}"));
+        group.throughput(Throughput::Bytes(size as u64));
+        group.bench_function("one_shot_64", |bench| {
+            bench.iter(|| hashcodecs::xxhash::xxh3_64(black_box(&input), 42))
+        });
+        group.bench_function("prepared_64", |bench| {
+            bench.iter(|| prepared.hash_64(black_box(&input)))
+        });
+        group.bench_function("one_shot_128", |bench| {
+            bench.iter(|| hashcodecs::xxhash::xxh3_128(black_box(&input), 42))
+        });
+        group.bench_function("prepared_128", |bench| {
+            bench.iter(|| prepared.hash_128(black_box(&input)))
+        });
+        group.finish();
+    }
+}
+
+fn prepared_batch(c: &mut Criterion) {
+    for items in [2, 4] {
+        for size in [241, 1024] {
+            let owned = (0..items)
+                .map(|index| data(size, index as u8))
+                .collect::<Vec<_>>();
+            let inputs = owned.iter().map(Vec::as_slice).collect::<Vec<_>>();
+            let prepared = hashcodecs::xxhash::PreparedXxh3::new(42);
+            assert_eq!(
+                prepared.hash_64_batch(&inputs),
+                hashcodecs::xxhash::xxh3_64_batch(&inputs, 42)
+            );
+            assert_eq!(
+                prepared.hash_128_batch(&inputs),
+                hashcodecs::xxhash::xxh3_128_batch(&inputs, 42)
+            );
+
+            let mut group = c.benchmark_group(format!("xxh3_prepared_batch/{items}_items/{size}"));
+            group.throughput(Throughput::Bytes((items * size) as u64));
+            group.bench_function("batch_64", |bench| {
+                bench.iter(|| hashcodecs::xxhash::xxh3_64_batch(black_box(&inputs), 42))
+            });
+            group.bench_function("prepared_64", |bench| {
+                bench.iter(|| prepared.hash_64_batch(black_box(&inputs)))
+            });
+            group.bench_function("batch_128", |bench| {
+                bench.iter(|| hashcodecs::xxhash::xxh3_128_batch(black_box(&inputs), 42))
+            });
+            group.bench_function("prepared_128", |bench| {
+                bench.iter(|| prepared.hash_128_batch(black_box(&inputs)))
+            });
+            group.finish();
+        }
+    }
+}
+
 fn xxhash(c: &mut Criterion) {
     support::pin_to_one_cpu();
     one_shot(c);
     batch(c);
+    prepared_seed(c);
+    prepared_batch(c);
 }
 
 criterion_group! {