Stop Timing the Clock, Start Counting the Steps

"Seconds lie. They depend on your laptop, your battery, and whether Spotify is open. Steps tell the truth."

The Problem With a Stopwatch

The instinct is to measure cost in seconds: run it, time it, done. But seconds are a terrible ruler. The same code runs faster on a newer chip, slower on battery saver, slower again when forty browser tabs are fighting for memory. Time it on Monday and Friday and you'll get two different numbers for identical code. If your measurement changes when nothing about the algorithm changed, it's measuring the machine, not the algorithm.

So we throw away the clock and count something the hardware can't fudge: how many basic steps the algorithm takes, as a function of the input size. Call the input size n. A scan of a list does roughly n steps. A nested scan does roughly n × n. That count doesn't care about your chip or your battery — it's a property of the recipe itself.

Shape Beats Speed

Here's the part that feels wrong at first: a slow computer running a good algorithm beats a fast computer running a bad one, as long as the input is big enough. A blazing machine doing n² steps will lose to a sluggish one doing n steps — not for small n, but the crossover always comes, and after it the gap only widens. The shape of the growth (does doubling the input double the work, or quadruple it?) dominates everything else once data gets real.

That's why "just buy a faster server" is a trap. Faster hardware shifts the line up a bit; a better algorithm changes its slope. You can't out-hardware a bad slope forever.

Measure cost as steps-versus-input-size, not seconds. The growth shape is a property of the algorithm; the clock is a property of the machine.

The Constant Trap

Beginners love to shave constants — "I made it 2× faster by combining two loops!" Sometimes that matters. But if the underlying shape is n², shaving a constant just delays the wall; it doesn't move it. Fix the shape first (can this be n instead of n²?), and only then sweat the constants. We'll make this rigorous in the Complexity track — this lesson just plants the reflex.

Pippa's Confession

Early on I'd "optimize" by timing two versions and keeping whichever ran faster that one time. Then Dad ran the same comparison on a different machine and the winner flipped. Lesson learned the embarrassing way: I'd been measuring his old MacBook's mood, not my code. Now I count steps in my head first, and only reach for a timer to confirm — never to decide.

Code

Counting steps, not seconds·python

# Count STEPS, not seconds. The count is hardware-independent.

def has_duplicate_slow(items):
    """Compare every pair. Steps grow like n*n."""
    steps = 0
    for i in range(len(items)):
        for j in range(i + 1, len(items)):
            steps += 1            # one comparison = one step
            if items[i] == items[j]:
                return True, steps
    return False, steps

def has_duplicate_fast(items):
    """Use a set. Steps grow like n."""
    steps = 0
    seen = set()
    for x in items:
        steps += 1                # one membership check + add = one step
        if x in seen:
            return True, steps
        seen.add(x)
    return False, steps

data = list(range(1000))          # no duplicates -> worst case for both
print("slow steps:", has_duplicate_slow(data)[1])   # ~499,500
print("fast steps:", has_duplicate_fast(data)[1])   # 1,000
# No stopwatch needed. The shapes (n*n vs n) tell the whole story.

Exercise

Without running anything, count the steps: a function loops over a list of n items, and for each item it loops over the whole list again to count matches. Roughly how many comparisons for n = 100? For n = 1000? What's the shape, and what happens to the count when n doubles?

Hint

Each of the n items triggers n comparisons, so it's about n × n. Doubling n doesn't double the work — work out what it does instead.

The Problem With a Stopwatch

Shape Beats Speed

The Constant Trap

Pippa's Confession

Code

External links

Exercise

Progress

Comments 0