19. Performance

Level: beginner · Reading time: 14 min · Prerequisite: book/chapters/18-tests.html · Track: essential · Maturity: reviewed · Last review: 2026-05-09

Prerequisites: book/chapters/18-tests.html. See also: book/chapters/18-tests.html, book/chapters/27-grammar.html, book/chapters/31-build-errors.html.

Concrete Problem

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

Red Thread (Single Project)

One data-processing path is measured before and after a structural improvement.

For what

This chapter helps the reader connect performance claims to concrete data movement and memory behavior.

What you are going to do

You will inspect one measurable flow, identify the costly boundary, and compare it to a safer or cheaper variant.

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.

Invalid case

proc noisy_accumulate(values: list[int]) -> int {
  if values { give 0 }
  give 0
}

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

Common pitfalls

• Optimizing before measuring the real boundary.
• Talking about performance without naming allocation or traversal cost.
• Using invalid examples that are only syntactic, not operational.

Short exercise

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

Summary in 5 points

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