rqe cost export: count top-k heaps, time top-k queries above the clock floor, add exact hash-table overhead

[zzylol]

Closes #146. Part of #147 (the "Per-op fixes").

Why

The per-phase cost model (#145) multiplies each cost-table row's memory and CPU by deployment counts, so a per-instance error is multiplied too. Three rows were measured inconsistently:

• CMS+heap and CountSketch+heap memory left out the top-k heap, while UnivMon counted its heaps. All three compete as TopK candidates, so they weren't compared like for like.
• A top-k query is one heap dump per pass. That is about 0.1 µs, far below what getrusage can resolve, so the recorded query CPU was mostly the cost of the measurement itself.
• Exact accumulators' memory counted keys and cells but not the hash table that holds them.

What

Only the benchmark's measurements change; the cost-table format is unchanged. After the next scripts/export_rqe_optimizer_costs.sh run:

• the top-k rows' memory includes the heap;
• the top-k rows' query CPU is the real cost of one heap dump;
• the exact rows' memory includes hash-table overhead.

How

• Heap memory: memory_cms_heap_lib_vector2d_{fast,regular} and memory_cs_heap_lib_vector2d_fast add CMS_HEAP_TOP_K × size_of::<HHItem>() (32 × 48 B), as memory_univmon_lib already does.
• Query timing: TopkGT::probes() asks its one question 1024 times (QUERY_TIMING_REPEATS), as CardinalityGT does for HLL. The CMS-heap (fast and regular), CountSketch-heap and UnivMon top-k queries dump the heap once per probe. The work count is the number of answers, so CPU per op stays per call. Scoring uses the first answer, so accuracy is unchanged.
• Exact memory: Multiple::footprint estimates hashbrown's table as capacity × (size_of key + size_of cell + 1 control byte), plus the strings and cell heap each group owns. Capacity is what is allocated, so the per-group share depends on the load factor at the measured group count: about 1.44 slots per group at the export's ~9.9k groups, and between 1 and 2 elsewhere.

Before this PR

Row	Memory	Query CPU per call
cms-heap 3×2048	24,576 B (counters only)	95.8 µs
countsketch-heap 3×2048	24,576 B (counters only)	2.8 µs
univmon-topk 3×1024, heap 500	heaps included	181 µs
exact-sum, per group	112 B (no table)	—
exact-increase, per group	176 B (no table)	—

Two top-k rows of the same shape differed 34× in query cost, and the numbers didn't track how much work a dump does.

After this PR

Row	Memory	Query CPU per call
cms-heap 3×2048	26,112 B (+1,536 B heap, +6%)	0.116 µs
countsketch-heap 3×2048	26,112 B (+1,536 B heap, +6%)	0.129 µs
univmon-topk 3×1024, heap 500	unchanged	6.44 µs (sorts its 500-item heap per dump)
exact-sum, per group	128 B (+14%)	—
exact-increase, per group	220 B (+25%)	—

Evidence

• Query CPU: clnode109 (idle 56-core, load ≈ 1), release builds of f130b23 (before) and a8ee5ed (this PR), --operations query --metrics throughput,cpu --runs 5 --warmup-runs 3, zipf s=1.1, 1M items, 100k keys, seed 42. CPU per call = total query CPU ÷ total calls.

  Row	Before: calls/pass, CPU/call	After: calls/pass, CPU/call
  cms-heap 3×2048	1, 95.8 µs	1024, 0.116 µs
  countsketch-heap 3×2048	1, 2.8 µs	1024, 0.129 µs
  univmon-topk 3×1024, heap 500	1, 181 µs	1024, 6.44 µs
  univmon-topk 5×2048, heap 1000	1, 549 µs	not measured (run stopped)

• Memory: deterministic, from release builds of the same two commits (--operations insert --metrics throughput,memory). cms-heap 3×2048 24,576 → 26,112 B; countsketch-heap 5×2048 40,960 → 42,496 B; exact-sum on hydra_columns.yaml (9,950 groups) 1,117,624 → 1,272,312 B; exact-increase on counter_columns.yaml 1,754,424 → 2,189,816 B.

Verification

• Unit tests: footprint_is_counters_plus_heap (cms_heap/mod.rs): the footprint is the counters plus a full heap of HHItems, for both the fast and regular paths. It replaces the old counters-only assertion.
• End-to-end tests: the before/after runs above.
• Other checks: cargo test --workspace, cargo clippy --workspace --all-targets -- -D warnings, CI (format-and-lint, test).

Architectural decisions

• The heap counts at full capacity (32 entries), matching UnivMon rather than the current fill.
• 1024 repeats, not HLL's 4096: a heap dump costs more than an HLL estimate, and 1024 already lifts a pass well above the clock floor.
• UnivMon top-k repeats too: it shares TopkGT, and the three top-k families should be measured alike.
• Exact memory is capacity-based (allocated bytes), not the length × ideal load factor; documented as measured at ~9.9k groups.

Limitations and follow-up

• Heap entries' out-of-line key bytes (e.g. string keys) aren't counted; the export uses i64 keys.
• Exact accumulators' per-group memory varies 1–2× with the group count through the load factor; the size sweep (rqe cost export: sweep items per instance and re-export (follow-up to #147) #157) can measure it.
• The cost table needs a re-export to pick these up (rqe cost export: sweep items per instance and re-export (follow-up to #147) #157).

Human review — do not complete with an agent

• The MVP boundary is correct.
• New conceptual layers or public interfaces are necessary.
• The before/after description matches the intended product behavior.
• Human reviewer:
• Decision and rationale:

🤖 Generated with Claude Code

[zzylol]

Grilling outcome (agreed with @zzylol):

• Q1: keep 1024 repeats; the comment now names getrusage (not Instant) as the timing floor.
• Q2: UnivMon top-k repeating too is intended: all three top-k families measured alike.
• Q3: full heap of 32 HHItems, same as UnivMon; out-of-line key bytes not counted.
• Q4: exact memory stays capacity-based (allocated memory); doc notes ~1.44 slots/group at ~9.9k groups, 1–2× elsewhere.
• Needs one re-export after this, rqe-optimizer: check accuracy at the query's merge count #154 and atomic-costs: record the measurement conditions on each cost-table row #155 merge.

🤖 Generated with Claude Code