In step 1 you wrote down two numbers: how many times more work, and how many times longer.

$ algo frontier
nodes 1000, edges 742, 561 reachable destinations from 0

                                   queue work         time
  binary heap (lesson 13)             5567392         32ms
  linear min-scan                   404796000        546ms

  identical cost on 561 of 561 destinations
  work ratio  72.7x
  time ratio  16.9x

First, the line without which the whole table would mean nothing:

identical cost on 561 of 561 destinations.

Changing the frontier does not change the answer. It changes only how long you wait for it. Which is what makes the other two numbers comparable at all.

And they do not match

work ratio   72.7x
time ratio   16.9x

The counter says the linear version does 72.7× more work. The clock says it takes 16.9× longer.

A gap of more than four.

Why the counter overstates

The linear scan's work is for v := 0; v < n; v++ over a contiguous array. A processor likes that loop: the addresses are predictable, the data arrives in batches, the branch goes the same way every time. One step there is cheap.

The heap's work is sifting up and down, jumping between 2i+1 and (i−1)/2 — the addresses skip about, every comparison may wait for memory, and the branch is unpredictable. One step there is dearer.

The counter calls both of them "one". They are not one.

The sixth time — and the first in this direction

The boundary is familiar by now, but until here it always cut the same way:

lesson	what the counter said	what the clock said
4	zero (memory is invisible)	the heap was growing
6	crossover at n ≈ 3	at n ≈ 6 — the instrument moved the measurement
11	identical: 5000.5 for both	a 4.5× difference
12	AVL 23% cheaper	AVL 1.65× dearer
13	identical for both heaps	a 1.66× difference
15	72.7×	16.9×

In lessons 4, 11 and 13 the counter understated the difference. In lesson 12 it got the sign wrong.

Here it overstates — for the first time in the course. And not because it is worse, but because it is measuring something else.

The counter measures how many operations are performed. The clock measures what performing them costs. When the operations are not alike, the two numbers separate — and both are right.

transit sees the same thing, larger

Our capture (docs/reference/transit-benchmarks.md), three queries:

query	linear frontier work	heap work	work ratio	time ratio
cross-city	92,200,762	370,053	249×	16.0×
slow-naive	95,179,989	370,009	257×	18.9×
worst-case	988,259,147	3,047,930	324×	16.4×

There the work ratio is 15–20× larger than the time ratio. Ours is 4.3×. Same direction, same mechanism, different scale.

And look at the time column: 16.0, 18.9, 16.4. Ours is 16.9. A different graph, different data, a different program — the same number.

That is the real size of the improvement a priority queue buys Dijkstra: roughly 16–19×.

What to take from it

Not "do not trust the counter". Lesson 1 chose it correctly and for the right reason — it does not depend on the machine, and a clock does.

But after fifteen lessons the answer is more precise:

The counter tells you how an algorithm GROWS. The clock tells you what it COSTS today, on this machine. Complexity needs the first; a decision needs both.