spatial locality

When you take one book off a library shelf, the next book you want is very often the one right beside it — same subject, same series, shelved together on purpose. A smart librarian would hand you a small armful of neighbouring books, not just the one you named. Spatial locality is this pattern in data: if a program accesses one memory address, it is likely to access nearby addresses soon, so it pays to fetch a whole neighbourhood at once.

Spatial locality is exactly why a cache does not store single bytes but whole fixed-size blocks called cache lines (commonly 64 bytes). When you ask for one byte and the cache misses, it pulls in the entire surrounding line — your byte plus its neighbours — on the bet that you will want those neighbours next. The most familiar source is array traversal: a[0], a[1], a[2]... sit consecutively in memory, so one line fetch front-loads several future accesses into fast hits. Sequential instruction fetch has the same character — the next instruction is usually the next address.

This is also why traversal order can change speed dramatically. Walking a 2D array along the way it is laid out in memory (row by row in a row-major language like C) marches through consecutive addresses and enjoys spatial locality; walking it the other way (column by column) jumps a whole row's width each step, defeats the cache line, and can run many times slower for the identical result. The honest caveat: spatial locality assumes a sensible data layout — scatter your data across the address space (linked lists of separately allocated nodes, for instance) and the benefit largely evaporates.