Scratch with an exit — Parallax Sketchbook

SKETCHBOOK / 02 The Living Gallery · 2-week chapter

Page 1 of 7: Measure the requests you actually make

PMR / accounting

Measure the requests you actually make

Begin with ordinary vectors and an instrumented workload before changing the allocator. Distinguish live requested bytes, capacity, retained arena storage, allocator metadata, and process memory. A small requested-byte counter is not a resident-memory measurement or a speed benchmark.

The first-course PMR reference wraps a fixed monotonic buffer with a counting resource and a null upstream. It demonstrates a hard local backing boundary and a controlled allocation failure. The promoted ordinary string is a separate owner that can survive arena release.

For the gallery, choose one scratch phase with a clear end, such as preparing a batch's temporary descriptors. Keep long-lived cached assets out of that arena until you can explain how they would be promoted or how the entire asset generation would own its storage.

TRY IT IN YOUR STUDIO

Record one ordinary workload allocation trace and label the units. Draw which bytes remain retained after containers release their logical requests.

From the page to your own work

Your studio assignment.

Give one gallery scratch phase an enforceable budget and reset boundary.

A finish line you can see

A PMR lifetime diagram, exhaustion test, and promoted result that survives reset.

Name backing storage, resource, containers, and worker owners.
Test failure without executing invalid access.
Show destruction before release.
Preserve the prior published asset on preparation failure.

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.

What does a counting memory_resource tell you that a process memory graph does not, and vice versa?

Counters can describe requested allocation sizes and logical liveness.
They omit retained arena space, metadata, and unrelated process allocations.
Neither metric alone proves a performance improvement.

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

A tip for this exercise

Treat scratch release as the end of a named preparation phase. Sketch backing storage, resource, containers, and any workers in lifetime order, then choose an ordinary owning type for the promoted result.

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

Find the value that must survive reset. Check whether copying its current type copies the bytes or merely copies a view into the scratch allocation.

2Hint 2 · Choose an approach

Use bounded backing storage with a null upstream for the exhaustion experiment. Finish and join any worker borrowers, promote the needed result into independent storage, then end container scopes before releasing the resource.

3Hint 3 · Check your reasoning

Force an oversized reserve and inspect retained valid values while their owners are still alive. After destruction and release, check only the promoted owner; never read the old scratch view to demonstrate failure.

A small creative variation ↗

Change the fixed budget and predict the first rejected request while keeping the accepted workload fixed.

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

Coming back after a break? ↩

Run prism-memory unchanged and locate the closing borrower scope before the release call.

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 Scratch with an exit

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 16 files