19. Performance (pocket version)

TL;DR (5 lines)

Performance claims need a concrete flow.
Allocation and traversal cost should stay visible.
Measurement should follow a clear boundary hypothesis.
Structural choices matter more than slogans.
The chapter should teach reasoning before micro-optimizing.

Concrete Problem

Performance chapters become hand-wavy when they talk about speed without naming what is being measured or allocated.

Coherent example

space demo/performance

proc accumulate(values: list[int]) -> int {
  let total: int = 0
  for value in values {
    set total = total + value
  }
  give total
}

Global explanation

A performance chapter should say what is being moved, copied, or traversed. Without that, 'faster' and 'slower' are just adjectives. The chapter needs one concrete flow that can be reasoned about before it is benchmarked.

Short exercise

Take the example and explain one reason why data shape, not just arithmetic, could dominate the cost.

Next best action

Keep the example small, reproduce it locally, then continue to the full chapter if you need the broader context.