Memory with a budget — Parallax Sketchbook

SKETCHBOOK / 06 The allocation workshop · 2-week chapter

Page 1 of 4: Start by removing accidental work

Allocation is a design decision

Start by removing accidental work

A first image should not require one allocation for every pixel. A vector can own a contiguous output buffer, and short-lived arithmetic values can stay ordinary local values. Inspect the renderer before replacing its allocator: needless ownership transfers, repeated growth, or per-pixel containers often explain more than the heap implementation does.

std::pmr separates a container’s interface from the memory resource that supplies its storage. A pmr::vector is still a vector: it still has size, capacity, invalidation rules, and element lifetimes. Passing a different resource does not make out-of-range indexing safe.

This lesson studies allocation policy in a separate executable. It does not claim that adding an arena makes the renderer faster. Keep the straightforward renderer as a baseline, and measure a real workload before integrating a memory policy.

TRY IT IN YOUR STUDIO

Find the renderer’s output allocation. Identify its owner and lifetime. Then look for allocations inside the pixel loop; record what you find before proposing a change.

Per.14Avoid unnecessary allocations and deallocations.

From the page to your own work

Your studio assignment.

Explain one bounded scratch lifetime. Keep allocator experiments out of the image path until there is a reason to integrate them.

A finish line you can see

Your own PMR experiment variation, a failure test, and a diagram of storage, resource, borrowers, and promoted output.

Change the requested workload or budget and predict whether it fits.
Observe a controlled allocation failure without using released storage.
Destroy every borrowing container before releasing the resource.
Explain why requested-byte counters are not process memory or a speed measurement.

Keep the evidence in your weekly notebook ↗

Explain it like an engineer

Try answering aloud before opening the review notes. Use your own implementation as evidence.

Why is calling arena.release() while a PMR vector is still alive unsafe?

The container borrows its resource and may still need its elements and storage.
release does not run element destructors or find surviving views.
Resource reset is separate from asynchronous completion and container cleanup.

These prompts support practice; they are not an automatic assessment of your work.

A tip for this exercise

Put backing storage, resource, borrowers, and promoted output on one lifetime diagram. Keep the allocator experiment separate from rendering until you can explain both its failure path and its retained storage.

Hints, when you need them.

Try a first step, then reveal as much help as you need. Each hint gets a little more specific.

1Hint 1 · Find a starting point

Locate the resource’s upstream choice and the borrower scope. Those tell you where an oversized request goes and when reset becomes possible.

2Hint 2 · Choose an approach

Change one request or budget, predict the outcome, and observe a controlled bad_alloc. Keep alignment in the explanation rather than treating buffer bytes as an exact element capacity.

3Hint 3 · Check your reasoning

In the 512-byte reference, locate the 4096-element reserve failure and verify the earlier values survive. After borrower destruction, check zero live requested bytes and an independently owned promoted string before releasing scratch.

A small creative variation ↗

Promote a different small result into an ordinary owning string before the scratch scope ends.

Optional. Save it for later if this chapter already feels full.

Coming back after a break? ↩

Run prism-memory unchanged. Identify the line that closes the borrower scope before changing any budget.

Books & principles behind this study +

Original Parallax explanations and assignments, with these works for further reading.

YOUR MARGIN NOTES

Leave yourself a good question.

What changed your mind? What would you try next?

Notes for Memory with a budget

Notes are private to this browser and saved as you write.

A CHECKPOINT, NOT A SCORE

Can you explain the idea and try the exercise yourself?

Completion records your own assessment. It does not compile or test your C++.

Companion source 5 files