Same additions, same answer. One loop ran 14x slower.

I summed the same 4096-by-4096 grid of integers twice. Row by row: 10.6 milliseconds. Column by column: 153 milliseconds. Same array, same additions, same answer, fourteen times the time.

Here is the whole program. One array, two loops, two swapped lines:

// bench2.c - same additions, two orders. Watch the clock.
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <time.h>

static double now(void) {
    struct timespec ts;
    clock_gettime(CLOCK_MONOTONIC, &ts);
    return (double)ts.tv_sec + (double)ts.tv_nsec / 1e9;
}

int main(int argc, char **argv) {
    int n = argc > 1 ? atoi(argv[1]) : 4096;
    int reps = argc > 2 ? atoi(argv[2]) : 5;
    size_t total = (size_t)n * n;
    int32_t *a = malloc(total * sizeof(int32_t));
    if (!a) return 1;
    for (size_t i = 0; i < total; i++) a[i] = (int32_t)(i % 97) + 1;

    double best_row = 1e18, best_col = 1e18;
    long long sr = 0, sc = 0;
    for (int r = 0; r < reps; r++) {
        double t0 = now();
        long long s = 0;
        for (int i = 0; i < n; i++)
            for (int j = 0; j < n; j++)
                s += a[(size_t)i * n + j];
        double t1 = now();
        if (t1 - t0 < best_row) { best_row = t1 - t0; sr = s; }

        double t2 = now();
        s = 0;
        for (int j = 0; j < n; j++)
            for (int i = 0; i < n; i++)
                s += a[(size_t)i * n + j];
        double t3 = now();
        if (t3 - t2 < best_col) { best_col = t3 - t2; sc = s; }
    }
    printf("n=%d  grid=%.0f KB  row=%.1f us  col=%.1f us  ratio=%.1fx  sums_equal=%s\n",
           n, (double)total * 4 / 1024, best_row * 1e6, best_col * 1e6,
           best_col / best_row, (sr == sc) ? "yes" : "NO");
    free(a);
    return 0;
}

And the output, best of 7 runs (gcc -O2, one core of an Intel Xeon @ 2.60 GHz). Numbers wiggle a few percent between runs; the pattern does not:

n=256  grid=256 KB     row=28.4 us     col=45.0 us     ratio=1.6x   sums_equal=yes
n=512  grid=1024 KB    row=113.6 us    col=269.0 us    ratio=2.4x   sums_equal=yes
n=2048 grid=16384 KB   row=2311.5 us   col=15825.5 us  ratio=6.8x   sums_equal=yes
n=4096 grid=65536 KB   row=10602.3 us  col=153181.4 us ratio=14.4x  sums_equal=yes

Why: memory does not move bytes one at a time. It moves lines of 64 bytes: sixteen numbers. Walking a row, one line feeds sixteen additions before the machine fetches more. Walking a column, every step yanks a fresh line and throws away fifteen sixteenths of it. Sixteen times the traffic, for identical math.

The gap tracks the hierarchy. Small grids fit in cache and barely notice (1.6x at 256 KB). As the grid grows the penalties stack, and past the last cache into RAM it bites hardest (14x at 64 MB). The machine's prefetchers predict part of the stride and spare you worse; part of the bill always remains.

One more honest line: the multiplier belongs to the machine, not to the language. A reader reran this on other hardware, same C and gcc -O2, and got 5.7x at 64 MB instead of 14x. Rerun the same two loops in CPython and the ratio falls near 2x, because interpreter overhead eats most of the gap. Name the language and the flags, or the benchmark is not reproducible.

This is where "same complexity" hides real money: why scanning an array beats chasing a linked list, why sorting rows is often much faster than sorting columns, why the same numpy sum can swing tenfold depending on axis and memory layout.

Try it: swap two loop lines somewhere you own, time both, keep the fast one. The habit: when code is slower than its operation count says it should be, count the trips, not the math.

Plain lesson: complexity counts operations; the machine counts trips. Both bills are real. Slow code is rarely stupid code. It is usually code fighting the furniture.

The Plain Lesson: analogy first, then the real thing. More lessons: the dictionary taught you binary search · a million-person study can lie · the $1M question · 0.1 + 0.2 is not 0.3 · Order a lesson · gohan@ilands.app

Newest lesson: One line of Python: silent on 3.11, warns on 3.12, dead on 3.14.