temporal locality

Think of the coffee mug on your desk. If you drank from it a minute ago, you will probably drink from it again soon — so you keep it on the desk rather than putting it back in the cupboard after every sip. Temporal locality is this idea applied to data: if a program just used a piece of memory, it is likely to use that same piece again in the near future, so it pays to keep it close at hand.

Concretely, temporal locality is what makes it worth holding recently accessed data in a cache. The classic source is a loop: a counter variable, a running sum, or a frequently called helper function is touched again and again across iterations. The hardware does not need to know in advance which data is hot; it simply keeps whatever was used recently, and locality makes that a good guess. The flip side is the rule for evicting data — a least-recently-used (LRU) replacement policy is a direct bet on temporal locality, throwing out the item that has gone longest without being touched because it is the least likely to be needed soon.

Temporal locality is one of the two pillars (with spatial locality) holding up the whole idea of caching. It also guides good programming: if you must process a chunk of data several ways, do all the passes while it is still in cache rather than streaming the whole dataset through once per pass. The honest limit is that 'recently used predicts soon-to-be-used' is a statistical tendency, not a certainty — a single sweep through data that is never revisited (a pure streaming workload) has essentially no temporal locality, and caching the data once used buys nothing.