docs(bench): efficiency findings + optimization scope (A6)#261
Merged
Conversation
The "scope the gap" step of the performance track. With the harness complete (A1-A5), this records where IronCache stands against the bar and scopes the optimization precisely, rather than rewriting the store waist speculatively. Indicative head-to-head (IronCache vs a redis-server 7.2.1 stand-in, unpinned macOS, 300k keys via scripts/bench/headtohead.sh): - bytes-per-key 527 vs 245 = ~2.1x HEAVIER. This is the reliable finding (a deterministic used_memory delta, not contention-sensitive) and the real gap. - qps-per-core ~parity (7151 vs 7528) but contention-bound on an unpinned, co-resident box, so NOT authoritative; IronCache's far lower p50/p99 (1006us vs 4187us; 2.5ms vs 65ms) suggests headroom a pinned run would expose. docs/bench/FINDINGS.md decomposes the memory gap with the A1 model (a fat per-slot KvObj value sized for its largest inline variant, ~160 B/slot, plus ~210 B/key Swiss-table slack at load) and scopes the levers, each as its own future effort now protected by the A5 perf-gate: L1 box the large KvObj variants to shrink the slot (highest impact), L2 a Dashtable-style compact index, L3 load-factor tuning; and for throughput, confirm on pinned Linux vs valkey 9.1.0 before optimizing (io_uring #28 is the lever if a real gap appears). A speculative store rewrite is deliberately deferred to the authoritative bar. README points to the findings. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Zeke <ezequiel.lares@outlook.com>
perf-gate (A5)Same-runner ratchet of HEAD against the merge-base (both rebuilt and measured in this job).
Overall: PASS
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A6, the "scope the gap" step. With the harness complete (A1-A5), this records where IronCache stands and scopes the optimization precisely instead of a speculative store rewrite.
Indicative head-to-head (IronCache vs redis-server 7.2.1 stand-in, unpinned macOS, 300k keys):
docs/bench/FINDINGS.md decomposes the memory gap (fat ~160 B/slot KvObj value + ~210 B/key Swiss-table slack) and prioritizes the levers, each its own future effort now protected by the A5 gate: L1 box the large KvObj variants (highest impact), L2 a Dashtable-style index, L3 load-factor tuning; throughput needs a pinned-Linux-vs-valkey run before optimizing (io_uring #28 the lever). Docs-only.
🤖 Generated with Claude Code