Assert memory ceilings with pytest-memray, and drop the benchmark memory metrics

[fishidaho]

Problem

Two mechanisms measured memory, and neither said quite what was meant.

The tests reset tracemalloc's peak around an operation and compared the delta to a hand-computed bound. The bound was rebuilt inline at each site, setup had to be fenced off by hand, and the number moved with the runner: the accumulator being bounded is nthreads * n_minor * width * 8 bytes, so the same assertion meant something different on a 4-core runner than on a 96-core one.

The benchmark suite recorded the same quantity across ~35 cases with the same portability problem, against ceilings that were already stale — generous figures taken before the memory fixes landed, with a README table tracking how far off they were.

Fix

pytest-memray ceilings in tests/, which is what anndata uses for this. It intercepts the allocator rather than Python's allocation hooks, and is enforced by having the plugin installed — no --memray flag, so CI needs no change.

Three conventions keep the ceilings meaningful:

• pinned_threads (new, in conftest.py) fixes numba's thread count, so the expected allocation is a property of the code and not the machine.
• Inputs and JIT warm-up live in module-scoped fixtures. A mark measures the test body only, so the array under test no longer has to be fenced off.
• Ceilings ride on each pytest.param, never request.applymarker — the plugin reads markers at collection time, so one applied from the body is silently ignored and the test asserts nothing.

The benchmark suite no longer measures memory. Each retired case has a counterpart:

retired case	now asserted by
minor_sum_peak_mb	test_minor_axis_reductions_allocate_nothing_nnz_sized[sum]
minor_extrema_peak_mb	...[max]
minor_getnnz_peak_mb	...[getnnz]
minor_selection_peak_mb	test_minor_axis_selection_allocates_no_nnz_sized_scratch
misaligned_matmul_peak_mb	test_misaligned_matmul_peak_is_bounded_by_the_accumulator_budget
peak_alloc_mb_view (30 cases)	the same test, parametrized over every recipe

Layout size and throughput stay: bytes_per_nonzero is the format's core claim and has no other guard, and the scipy-relative timings have no test equivalent. 24 gated cases remain.

Measurements

Allocations at 4 pinned threads, all two orders of magnitude under nnz-scale:

operation	allocates	nnz-scale for the same input
minor-axis sum / getnnz	20 KB	8 MB
minor-axis max	40 KB	8 MB
misaligned matmul	132 KB	3.8 MB

Every ceiling was checked by tightening it to 1 KB and confirming it fails. The limit_leaks test was checked against a deliberately retained result.

Selection gets a ceiling above its output (2.3 MB — a selection's result legitimately grows with what was selected) and below output-plus-an-nnz-sized-temporary.

Neither tool sees RSS, so neither catches allocator fragmentation — the failure behind #49's 140 GB. That is documented in benchmarks/README.md as diagnosable but not reliably gateable.

Merge order

After #55, which it conflicts with in benchmarks/: the cases #55 adds carry peak_alloc_mb keys this PR removes. Landing second means dropping those keys.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Rvu3cf8ZL7F5EPX22eo6Je

[fishidaho]

Removed the limit_leaks test. It ran in 0.06s when I added it and verified it against a deliberately retained result, but on a 48-thread machine it now hangs indefinitely — the rest of that file completes in 1.4s. A test that is sometimes instant and sometimes never returns cannot go in CI, and it would have hung developers rather than the runner, since CI's lower core count got through it.

The limit_memory ceilings are unaffected and remain the substance of this PR. Cache-growth-with-use is no longer covered by a test; noted here rather than papered over.

Docstrings and comments trimmed throughout to say what the code does rather than how it got here.