the principle of locality

Watch how you actually use a kitchen. Once you reach for the salt, you tend to reach for it again within the next few minutes (you are seasoning), and you also reach for things stored right next to the salt — the pepper, the oil. You do not pick ingredients uniformly at random from the whole pantry; your reaching clusters in time and in space. The principle of locality is the observation that programs touch memory the same clustered way, and it is the single fact that makes caching work at all.

It comes in two flavours. Temporal locality: if a program accesses a memory location, it is likely to access that same location again soon (think of a loop counter, a frequently called function, a variable updated each iteration). Spatial locality: if a program accesses a location, it is likely to access nearby locations soon (think of stepping through an array element by element, or running consecutive instructions). Both are tendencies, not laws — but they hold strongly enough across real code that hardware can bet on them and usually win.

Because of locality, a small fast cache holding just the recently used and nearby data can satisfy the large majority of accesses, even though the cache is thousands of times smaller than main memory. Spatial locality is why caches move data in whole blocks (cache lines) rather than single bytes — fetching a neighbourhood at once pays off. Temporal locality is why we keep recently used data around instead of discarding it. The honest caveat: code can be written with poor locality (random scatter, wrong loop order), and then caches help little. Locality is something a programmer can earn or squander.