Fifteen lessons. One counter, one library, twelve structures. Worth collecting what is left.

Sorted input, the fourth time

You built the -sorted flag in lesson 1, and three times since then it has been trouble:

lesson	what sorted input did
7	insertion sort's best case
8	quicksort's worst, O(n²)
11	the BST's catastrophe: height n, the same 5000.5 as a linear scan
15	CSA — the entire condition of its working

The fourth time, order is neither the best case nor the worst. It is the reason the algorithm exists at all: CSA does nothing a plain loop would not do, and wins by 76× purely because the data already lies in time order.

The same property, four different roles. Data is not good or bad — it suits what you are doing with it, or it does not.

What the counter cannot see — six occasions

Step 5 collected the table. The rule it gives is one line:

The counter measures how many operations. The clock measures what they cost. Complexity needs the first; a decision needs both.

Lesson 1 chose the counter not because it is better but because O(n²) has no unit in milliseconds. That is still true. But lesson 11 showed the same comparison count costing 4.5× different, and this one shows 72.7× more work meaning 16.9× more time.

When an abstraction is free

Three measurements, one rule (lesson 13):

An abstraction is free when the compiler can see through it. It is expensive when it forces the data to be boxed on an operation too small to hide the cost.

sort.Search won. container/list tied. container/heap lost by 1.66× — and in this lesson transit shows the same thing inside Dijkstra: 1.37×. Four independent measurements, one cause.

Three structures, one question

Lessons 10 to 12:

	what it bought	what it paid with
hash table	O(1) exact-key lookup	all order
BST	order and every operation that comes with it	the guarantee
AVL	the guarantee back	the constant — insertion 1.65× slower

And lesson 15 adds a fourth row, of a different kind:

	what it changed	what it bought
CSA	the question	76× — and the structure disappeared

The last thing

Three steps in sequence, on the same problem:

• linear scan → heap: ~16–19×;
• heap → A*: a loss, because the heuristic could see 4.1% of the cost;
• Dijkstra → CSA: another 76×, and the priority queue vanished entirely.

Tuning the priority queue bought about 20×. Understanding the structure of the problem bought another 76× and deleted the queue.

A general algorithm is what you reach for when you do not know the shape of your problem. Once you do, you can often do better.

Dijkstra is correct for any weighted graph with non-negative edges — which is why it is the first answer. CSA is correct only for timetables, and only for the question "when is the earliest I can arrive" — which is why it is 76× faster.

Neither of those facts is a compromise. They are the same idea from two sides.

What you actually have

You now know a dozen structures and something like twenty algorithms. But the course was not about them.

In every lesson the route was the same:

1. ask a specific question about your data;
2. measure what each option charges for it — in comparisons and on the clock, because they say different things;
3. name what the option CANNOT do, not only what it does slowly;
4. ask whether the worst case is unpleasant or unacceptable;
5. and check the assumption the whole construction rests on — because once it was bytes instead of runes, once it was non-negative edges, and once it was the insertion order.

The structures will change. Those five will not.