46. ​​Performance: adapted data structures

Level: intermediate · Reading time: 9 min · Prerequisite: book/chapters/45-performance-allocations-copies.html · Track: supplemental · Maturity: draft · Last review: 2026-05-09

TL;DR (5 lines)

  • Data structures are architectural choices.
  • Use cases matter more than names.
  • Aggregation flows are better teaching units than isolated declarations.
  • Broken examples should show a mismatched shape.
  • Container choice should remain visible in the code story.

Frequent mistakes

  • Listing containers without an access pattern or use case.
  • Treating structure choice as style instead of behavior.
  • Hiding where grouped data enters and leaves the block.

Prerequisites: book/chapters/45-performance-allocations-copies.html. See also: book/chapters/45-performance-allocations-copies.html, book/chapters/27-grammar.html, book/chapters/31-build-errors.html.

Concrete Problem

Readers often see containers as names only, not as data-shape decisions embedded in a complete flow.

Red Thread (Single Project)

One report-building flow stores values, aggregates them, and returns a grouped result.

For what

This chapter helps the reader choose structures based on access pattern and meaning.

What you are going to do

You will read one grouped-data scenario, identify why the container exists, then inspect a broken variant.

Coherent example

space demo/collections

form Metrics {
  count: int
  total: int
}

proc absorb(values: list[int]) -> Metrics {
  let count: int = 0
  let total: int = 0
  for value in values {
    set count = count + 1
    set total = total + value
  }
  give Metrics(count, total)
}

Global explanation

Collections pages are useful only when they explain why a shape exists. The example shows aggregation as a real need for a container-like surface instead of presenting structures as vocabulary alone.

Invalid case

proc bad_metrics() -> int {
  let values: int = [1, 2, 3]
  give values
}

This invalid case is intentionally small. It exists to isolate the contract failure that the chapter is trying to teach.

Common pitfalls

  • Listing containers without an access pattern or use case.
  • Treating structure choice as style instead of behavior.
  • Hiding where grouped data enters and leaves the block.

Short exercise

Replace the single summary form with two grouped buckets and explain why the new shape is justified.

Summary in 5 points

  1. Data structures are architectural choices.
  2. Use cases matter more than names.
  3. Aggregation flows are better teaching units than isolated declarations.
  4. Broken examples should show a mismatched shape.
  5. Container choice should remain visible in the code story.

Mini quiz

  1. What contract is the coherent example trying to make explicit?
  2. Why does the invalid example fail?
  3. What boundary should remain visible if you extend the example?

See also

Next best action

Extend the coherent example by one small, justified step and keep the same contract visible from input to output.