[zzylol]

A new KLL allocated its whole item buffer at construction (1,796 items, about 14 KiB, at k = 469) and a k-sized merge scratch buffer (about 3.7 KiB). Most per-series sketches in a pane store hold a handful of items, so creating them was dominated by allocating and zeroing memory they never use. In a per-sample ingestion profile, KLL creation was about a third of data-plane CPU, mostly memset and page faults.

• Lazy item buffer. The buffer starts empty, then holds 16 items, and doubles up to the sketch's max_capacity. Growing moves the retained items to the high end of the new buffer and shifts every level boundary by the growth.
• Results are unchanged.
  • Compaction reads only level sizes and positions relative to one another.
  • A full buffer compacts only once it has reached max_capacity, as an eagerly allocated one did. When a partial buffer fills, every level is already within capacity (L0 compacts right after the insert that overflows it).
  • So the retained items, their order, the coin tosses, quantiles, merges and serialized bytes are those of the eager buffer for the same input and seed.
• The merge scratch buffer starts empty and grows on first use.
• merge, clear, from_portable_state and both decoders (the ASAPv1 payload and the nested serde form) size the buffer to what they hold. A decoded sketch's buffer holds just its retained items.
• The full-buffer path (grow, or compact once whole) moved into a #[cold], out-of-line make_room, so the insert path stays small.
• New: KLL::memory_bytes() and KllSketch::memory_bytes(). They report the bytes a sketch holds: the struct, its item buffer, its level array, its merge scratch space, and a memoized CDF when one is held. A caller that charged a KLL a fixed size can charge what it holds. A k = 469 sketch with 10 items holds 872 bytes, against 18,864 before.

Tests:

• kll::tests::lazy_allocation_matches_eager compares every level's retained items, in buffer order, and the coin state with a test-only copy of the eager allocation path (kll/eager_reference.rs).
  • It covers k = 8, 64, 200, 469 and 1024; inputs of 0, 1, 10, k − 1, k, k + 1, 3k, 10k and 50,000 items; and two seeds.
  • Each case then merges a second sketch and adds more items.
  • The serializers write exactly that state plus k, m and the seed, so equal state means equal bytes.
  • An extra coin toss on growth makes it fail.
• kll::tests::memory_follows_the_items_held and portable::kll::tests::memory_bytes_follows_the_items_held.
• kll_round_trip_rmp now compares level boundaries relative to the first retained item. The restored buffer holds just the retained items, while the source's buffer grew in doublings, so absolute positions differ. Level sizes and items are compared as before.

Benchmark (release, one pinned core, main e0f5711 vs this branch, alternating runs in one session, median of 3):

	main	this branch
Create 1,000,000 KLLs (k = 469), 10 updates each, held 10,000 at a time	13,710 ns/sketch	1,240 ns/sketch (11.1× faster)
Peak RSS of that run	178 MiB	10 MiB
One KLL, 50M updates, k = 469	33.69 ns/update	33.90 ns/update (+0.6%)
One KLL, 50M updates, k = 200	33.31 ns/update	33.65 ns/update (+1.0%)

• Stream cost: an earlier 5-pair pass measured about +1.8% for the stream. perf stat over the stream run shows this branch executing 0.7% fewer instructions with the same branch, L1, LLC and dTLB misses. Per-function cycle shares are within 1.5 points of main's. So the remaining difference is in code layout, not extra work on the insert path.

Verification: cargo fmt --all -- --check; cargo clippy --workspace --all-targets with and without --all-features, -D warnings; cargo test --all-features --locked (2,331 passed) and cargo test --locked (2,070 passed).