HydraCache 0.73.0

HydraCache 0.73.0 — Evidence-driven performance efficiency

Status: shipped 2026-10-03 from exact candidate
d1db9937e61295341ac95f289bace275641b1650, tagged v0.73.0.

0.73 applies six narrowly scoped runtime improvements only after owner attribution, local
falsification, and focused paired qualification. It reduces expiry-scan key copying, shares
immutable event bytes and tags, transfers RESP output buffers without a redundant copy, bounds
HC/2 queued outbound bytes, and caches the durable-store budget total while preserving its
validating public scan. Management overhead produced a measured no-win; allocator work remains
deferred behind an external profiling blocker; retained-byte admission was not applicable.

The Moka removal observer needed by production accounting is supplied by the independently
published, exact-pinned hydra-moka 0.12.15-hydra.1 package. Its runtime source is byte-equivalent
to the reviewed Git revision, but the registry package is deliberately treated as a new build
identity. HydraCache does not depend on acceptance of the upstream Moka proposal to publish 0.73.

Compatibility and claim boundary

The runtime changes preserve public APIs, HC/1, HC/2 and RESP bytes, tagged-key and TTL semantics,
tenant isolation, durable record/checksum/fsync formats, Management Center truth semantics, and
same-disk rollback. The final exact-tree admission checked 44 public package/profile rows against
the published compatibility baseline with cargo-semver-checks 0.50.0 and Rust 1.94.0; all 44
were classified compatible.

No portable numerical performance improvement is claimed. Five-pair focused host comparisons passed
the frozen goodput, CPU/op, p99, correctness and resource guards for the earlier exact candidate.
Six-hour run 36532416869 and 24-hour replacement confirmation 36839197349 passed every frozen
guard for the exact final registry candidate. In the confirmation, each role completed 1.0368
billion operations and 1,442 checkpoints with zero errors, timeouts or rejections. Goodput was
effectively unchanged, CPU/operation increased 0.260%, p99 improved 0.328%, and the decisive
RSS/anonymous-PSS 95% upper slope bound fell 32.60%. These results admit final C73 but do not claim
portable capacity, allocation savings, or Redis/Hazelcast superiority.

What the measurements actually showed

The figures below are deliberately split by evidence class. Local allocation and process screens
identify owners and can reject a change, but they are not portable release benchmarks. Only the
dedicated-host rows are release admission evidence, and their fixed 12,000 operations/second load
must not be presented as HydraCache's maximum throughput.

Area	Observation	Honest conclusion
Expiry scan	The fixed 256-entry local fixture removed exactly 43,008 gross allocated bytes and 769 allocations per bounded scan. Depending on expired cardinality, gross allocation fell 41.25% to 99.78%.	Borrowing examined keys removed the attributed clone owner. Percentages apply only to this local fixture; no CPU, p99, RSS or portable throughput claim follows.
Cache-event tags	In the primary local cell, gross allocation fell from 15,628,164 to 8,686,476 bytes (-44.42%). Per-delivery tag churn fell from about 55.87 to 24.00 bytes with one subscriber and from about 56.00 to 3.01 bytes with eight subscribers.	Sharing immutable tag slices removed repeated delivery copies while membership and invalidation controls stayed green. These are non-promotable allocation results.
RESP encoding	At 1 MiB, the four RESP2/RESP3 bulk and array cells reduced gross allocation by 49.96% to 50.00%, with identical wire bytes and 70 unchanged decode/translation cells. Local elapsed reductions of 32.7% to 41.4% were diagnostic only.	The redundant full output-frame allocation is gone. The run does not establish end-to-end latency or Redis-relative throughput.
HC/2 backpressure	With 256 KiB values, the stalled dispatch median fell from 128 to 104 (-18.75%), paired server working-set delta from 22,667,264 to 15,949,824 bytes (-29.63%), and pagefile delta from 22,663,168 to 15,167,488 bytes (-33.07%). The 4 KiB dispatch median was effectively unchanged, 4,160 to 4,152, and its memory ranges overlapped.	The new one-MiB application-queue byte budget bounds the attributed queue. It does not bound tonic, HTTP/2, TLS, socket or allocator retention, and it is not a small-frame improvement claim.
Management Center	Existing aggregate caching reduced the local cold-to-hit allocation median from 599,684 to 362,949 bytes (-39.48%) and elapsed median from 604.2 to 410.9 microseconds (-31.99%), but no candidate produced a defensible additional win.	W6 closed as measured-no-win; 0.73 makes no Management Center optimization claim from this work.
Durable budget admission	At 256 records, gross allocation per fill fell 80.65% for 64-byte values and 91.49% for 4 KiB values; overwrite fell 92.52% and 96.01%. Reopen validation cost rose at most 4.68%, inside the frozen 10% guard; maximum GC regression was 0.114%.	Caching the validated logical total removed the repeated full-store decode. This does not measure device write amplification, file-cache residency, flush latency or server p99.
Allocator experiment	On the local Windows trace, mimalloc finished 4.13% sooner and incurred 90.80% fewer refill page faults, but post-idle working set was 8.75% higher and private commit 11.71% higher than the system allocator.	Neither allocator dominated. The system allocator remains the default and the Linux three-allocator study is deferred; no allocator win is shipped.
Six-hour qualification	Each role completed 259.2 million operations with zero errors, timeouts or rejections. Candidate CPU/op rose 0.316%, p99 rose 0.274%, and the memory-slope upper bound fell 28.48%; all preregistered guards passed.	This admitted the candidate to confirmation; it was not itself final confirmation or a capacity benchmark.
24-hour confirmation	Each role completed 1.0368 billion operations and 1,442 checkpoints with zero errors, timeouts or rejections. At the fixed load, goodput was 12,000.0430 ops/s on both sides, CPU/op rose 0.260%, p99 moved from 7,311 to 7,287 microseconds (-0.328%), and the RSS/anonymous-PSS 95% upper slope bound moved from 30.1448 to 20.3181 bytes/s (-32.60%).	The integrated product candidate stayed inside every frozen regression and boundedness guard for 24 hours. One paired host run is not a portable speedup, maximum-throughput result or comparison with Redis/Hazelcast.

The machine-readable sources for every row live under
docs/testing/performance/0.73.
The byte-exact long-run packets are not stored only in Actions: the immutable branch and
commit-pinned archive below are the durable source of record.

Evidence archive

The permanent W11 archive is assigned to branch
evidence/0.73/w10-confirmation.
Its immutable archive is commit
570a5bcb6959ecc7f01f8c80d0fc32b719832ad9.
The artifact manifest
and SHA256SUMS
pin every accepted, rejected and interrupted attempt. Outer and nested SHA-256 values,
I73-to-C73 continuation handoff, identities, workload, duration, estimator, thresholds and all five
guards were independently verified.
These commit-pinned links remain the release record after provider retention expires.

The branch is append-only; expiring GitHub Actions artifact links are not the release archive.

Release closure

The exact tagged tree passed contract, compatibility, packaging, supported-target and
release-evidence admission. CI run
37140860241, documentation run
37140860224, and HC/2 run
37140860295 all completed
successfully. The PR synthetic merge tree and candidate tree were both
5bea41dd43278a9405648939666de5024d2164cc; the product-runtime diff from measured candidate
16d2e98b6cc9e22d9ccf95eb26fe28bbbcf80f2b remained empty. Local final admission ran 3,472 tests
with 3,472 passing and 82 skipped by the reviewed profile; performance-contract-check --require-ship passed and release-evidence --require-ship reported all 12 work items ship-ready.
The machine-readable record, including provider and nested artifact hashes, is
w11-exact-sha-ci-passed-37140860241.toml.

Failed and interrupted attempts remain append-only. Three local final-gate attempts were also kept
in the W11 record: two exhausted local disk during a cold isolated build/link, and one hit the
unchanged 360-second per-test limit while warming the compile-test cache. The same command then
passed on the unchanged exact SHA and unchanged limits. None of these infrastructure attempts is
reclassified as product evidence, and neither duration run authorizes a portable RSS, allocation,
capacity, Redis or Hazelcast comparison.

The first final exact-tree admission was PR
#214. Its head was the measured candidate
16d2e98b6cc9e22d9ccf95eb26fe28bbbcf80f2b; GitHub's synthetic merge commit
269f7fafccfd8b912fb6ad4957d905c65a97044a had the same tree
92336607f21a68f563e65dc0fccccd8efaa14f7b. HC/2 run 37126998936 passed, but CI run
37126998956 and documentation run 37126998896 failed. The root failures were a 0.72-versioned
docs example lockfile in the 0.73 workspace, incomplete CI-topology, memory-owner and gated-test
registries, one retained compatibility test that required the workspace to remain exactly 0.72,
and an instruction tripwire that emitted no benchmark summaries. Downstream admission failures
were fail-closed consequences, not independent green evidence.

The failed attempt remains immutable historical evidence at
w11-exact-sha-ci-rejected-37126998956.toml.
The corrected candidate was authorized to repair publication inputs and CI orchestration only. Its
product runtime paths are unchanged from measured candidate
16d2e98b6cc9e22d9ccf95eb26fe28bbbcf80f2b; therefore the accepted six- and 24-hour product
measurements remain attributable. Documentation, governance, packaging, compatibility and
instruction-tripwire gates were repeated on the corrected exact SHA and passed. The corrected local
release tooling also executes the
workspace format check package-by-package on Windows, avoiding process command-line error 206
without weakening rustfmt --check; Linux CI retains the canonical cargo fmt --all invocation.
Its Windows Clippy path now matches the supported allocator matrix used by cargo xtask verify:
all features for non-runtime workspace crates, plus explicit common, system-allocator and mimalloc
runtime lanes. The unsupported Unix-only jemalloc build is not invoked on Windows; Linux retains
the all-features gate that covers jemalloc. This repairs release orchestration without changing the
measured product candidate or suppressing warnings.

The second exact-tree attempt used corrected SHA
58419e64627d27f8a0b2c61d24959638479ff2f4; its PR merge tree was byte-identical to candidate tree
f84d209c5d779b9584af78ffdabf139fcc01e920, and the product-runtime diff from measured SHA
16d2e98b6cc9e22d9ccf95eb26fe28bbbcf80f2b was empty. Documentation run 37138395690 and HC/2
run 37138395655 passed. CI run 37138395653 still failed for two release-tooling reasons rather
than a measured product regression: cargo-semver-checks 0.49.0 could not analyze rustdoc JSON v61,
and the primary Rust job's floating stable channel resolved to Rust/Clippy 1.99.0, introducing
new fetch_update deprecations and double_must_use findings, including generated-code findings,
under the unchanged -D warnings policy. The exact record is
w11-exact-sha-ci-rejected-37138395653.toml.
The final candidate therefore pins the reviewed Rust 1.94.0 toolchain in both release-critical jobs
and updates only the analyzer to cargo-semver-checks 0.50.0, which supports v61. It keeps Clippy's
warning policy and feature/allocator matrix intact and does not change product runtime to satisfy a
newer compiler. This second failed attempt remains immutable evidence and was not rerun. The new
exact candidate then passed all three normal PR workflows and became tag v0.73.0.

The tag push exposed one more release-orchestration defect. Tag run
37149833980 completed 35 jobs
successfully, skipped 14 by their declared conditions, and failed exactly one of 50 jobs: Redis Compatibility Release Proof. That job alone still selected dtolnay/rust-toolchain@stable, which
resolved to Rust/Clippy 1.99.0; its unchanged -D warnings Clippy command stopped on the same new
fetch_update deprecations and generated double_must_use findings before the Docker/client/oracle
and resource-smoke steps could run. The rejected attempt is retained in
w11-tag-ci-rejected-37149833980.toml.

Tooling commit a60fd380c90bf2c1c0445f0baedcbf46eebbdc8f removes all 21 remaining floating
Rust action refs, pins the reviewed 1.94.0 toolchain, adds a regression contract, and adds a focused
manual repair path that requires a full candidate SHA and verifies git rev-parse HEAD. Focused run
37150976176 checked out the
unchanged tag commit d1db9937e61295341ac95f289bace275641b1650: fast checks, formatting,
Redis contracts/tests, server lifecycle checks and Clippy passed; the real Docker/client/oracle
matrix reported 21 passed and zero failed, and resource smoke reported two passed and zero failed.
The complete repair workflow then closed with 14 successful jobs, 27 conditionally skipped jobs and
zero failures or cancellations.
The accepted repair is retained in
w11-redis-proof-repair-passed-37150976176.toml.
The failed tag run is not rewritten, the tag is not moved, and neither the product candidate nor the
six- and 24-hour measurement inputs are changed or repeated. This closes a compatibility proof; it
does not add a Redis throughput, capacity, latency or superiority claim.