Explain how stream laziness enables operation fusion and short-circuiting, and what defeats these optimizations.

## Laziness is the enabling property Intermediate operations (`filter`, `map`, `peek`, …) are **lazy**: invoking them only *appends a stage* to the pipeline description. No element is touched until the **terminal** operation runs. This single fact unlocks two distinct optimizations. ## 1. Operation fusion (single-pass processing) Naively, `list.stream().filter(p).map(f).collect(...)` might run `filter` over the whole list to build a temp list, then `map` over that to build another, then collect. That would be three passes and two throwaway collections. Instead, the stream framework **fuses** the stateless stages. It pulls **one element** from the source and pushes it all the way through `filter → map → terminal` before pulling the next. The stages are composed like nested function calls; there is **one pass** and **no intermediate collection**. Adding more stateless intermediate ops adds work *per element* but not extra passes. Mechanically this is a *push* model (a `Sink` chain): each stage wraps the next and forwards accepted elements downstream, dropping or transforming as it goes. ## 2. Short-circuiting (early termination) Some operations don't need to see every element: - **Terminal short-circuiters:** `findFirst`, `findAny`, `anyMatch`, `allMatch`, `noneMatch` — they can conclude as soon as a single element decides the answer. - **Intermediate short-circuiter:** `limit(n)` — once `n` elements have passed, it tells upstream to stop. Because the pipeline pulls lazily, short-circuiting means the source is asked for **only as many elements as needed**. This is precisely what makes an **infinite source** work: ```java Stream.iterate(1, i -> i + 1) // infinite .filter(i -> i % 7 == 0) .limit(3) // short-circuits the infinite source .toList(); // [7, 14, 21] ``` Without laziness + short-circuiting, this would never terminate. ## What defeats fusion: stateful operations and barriers Not all intermediate ops are stateless. **Stateful** operations must see more than one element — sometimes *all* of them — before they can emit: - **`sorted()`** — must buffer **every** element, sort them, *then* emit. It is a full **barrier**: nothing downstream runs until the source is exhausted. This also breaks short-circuiting upstream of it (you can't sort an infinite stream). - **`distinct()`** — must remember elements seen so far (a hash set) to drop duplicates; bounded state but still stateful. - **`limit(n)` / `skip(n)`** — stateful (they count), and in **ordered parallel** pipelines they become expensive because order must be preserved. A barrier like `sorted()` splits the pipeline into segments: the part before it runs fully into a buffer, then the part after it streams from that buffer. So `filter(...).sorted().map(...)` is not a single fused pass end-to-end. ## What else costs you - **Encounter order in parallel:** an **ORDERED** parallel stream must reassemble results in source order, adding coordination overhead. If order doesn't matter, `unordered()` (or `findAny` over `findFirst`, `forEach` over `forEachOrdered`) can recover performance. - **Boxing:** using `Stream<Integer>` instead of `IntStream` adds per-element boxing; not a fusion issue per se but a real cost in tight pipelines. - **peek for real work:** `peek` is for observation and may be skipped/optimized when results are unaffected; don't rely on it for side effects. ## Practical consequence: operation order Because stateless ops fuse and stateful ones create barriers, **order matters**: - **Filter early** — `filter` before `map`/`sorted` shrinks the element count *before* the expensive stage, so fewer elements get mapped/sorted. - **Put `limit` before `sorted` only when correctness allows** — but note `sorted` itself can't be skipped by a later `limit` (it must sort everything first; there is no automatic top-N fusion). - **Avoid redundant stateful ops** — e.g. don't `distinct()` a source already known DISTINCT (the spliterator characteristic lets the framework skip it anyway). ## Terms defined - **Stateless operation:** processes each element independently, holding no accumulated state (filter, map). - **Stateful operation:** needs state spanning multiple elements (sorted, distinct, limit). - **Barrier:** a stage that must consume its entire input before producing output, breaking single-pass flow. - **Sink:** the internal push-model interface; each pipeline stage is a Sink forwarding to the next. - **Short-circuit:** terminate traversal as soon as the result is determined.