What a stored object costs in memory

[bjmeetsfo]

What a stored object costs in memory, and why the first measurement lied.

An index item here holds its key as a String and its ids as u64s, and an address is 64 bytes on
its own. Whether that is where the memory goes was a question, so this asks it the way that answers:
hold the object count fixed and vary the value size. A cost that tracks the VALUE is data being
retained; a cost flat in the value size is per-object structure. They want different fixes.

Twenty thousand objects, a cache small enough to hold nothing, debug build:

value    32 B      272 B per object
value   256 B      272 B per object
value 1,024 B      272 B per object

Flat. So it is structure, not data: 272 bytes to hold a fourteen-byte key and where its page lives
-- the key as a String, a BlockAddress of 64 bytes, a map entry for each, and an entry in each
of the two side maps a carried page needs.

The part that is worth more than the number. The sizes are measured in more than one position on
purpose. Run in one order, the first size reads about 1,233 bytes per object and every later one
reads 272 -- and the outlier follows the POSITION, not the size. That is the allocator taking its
arena once and charging it to whoever went first. Ask for a size again at the end and it reads about
1 byte per object, because the arena is already there. A single-pass version of this test would have
reported whichever number it sampled and looked entirely credible either way.

This corrects a figure taken earlier in the same investigation. Peak resident memory during a
populate suggested about 732 bytes per record; that folds in the process baseline and this same
one-time growth. 272 is the number that survives being asked twice.

The probe is #[ignore], so it costs nothing on a normal run.