I'm going to do the thing where I quote sentences from your comment and respond to them individually, which IMO is normally pretty aggressive -- just wanted to say I'm doing that for organization's sake, not for any other reason.

"Most people have several stores for clothes..." I'd argue that most of those are acting like FILO queues anyways, since you typically don't need random access to clothes in a washing machine/from the to-be-washed pile.

"On days that I need to be out of the house particularly early, I will "cache" my next day's clothes..." you're still spending the same time overall ((sum over all day's clothes(time(access clothes)) + time(get dressed)) to get your next day's clothes, so preloading them just reduces the time spent when in the mornings when deadlines are tight. That's a totally valid technique, but it isn't caching as described in the article, which is described as a technique for mitigating the cost of frequently accessing high latency resources, since you (probably) only infrequently access clothes to wear. In that case, the time spent overall is (probably) dominated by the lookup times for single articles of clothing, so excellent organization is (probably) the best way to cut down on overall time. You'd need to profile to determine whether it could be of use, though.

"I've got a cache of stuff that I need on a daily basis..." that's actually quite valid! I had mentioned b-trees ]1] jokingly, but they can be analogized to what you're describing (feel free to skip the next section if you're already familiar with them). Idea in a nutshell: since hard drives are slow and return data in blocks (you can think of it as retrieving shelves of data at a time instead of individual items), it makes sense to pack as much relevant information as possible (spatial locality) [2] into each block (which b-trees do by having a large branching factor and including data inside of nodes). The relationship to placing items in discrete groups around the house is quite similar: physically moving (following a pointer) is quite slow, so once you're somewhere (a block), you want everything of import to be nearby (high locality, no need to follow more pointers). This is _still_ not caching, since you weren't going to sit down and perform some access intensive operations on your wallet and keys in the morning, but it does have some distant relationship to a CS data structure :)

Or, at least, that's my take on it.

edit: I'd just like to mention that I don't follow any of that advice and just use a roughly sorted laundry bin to keep most of my clothes in a single place, if not in any particular order.

[1]: https://en.wikipedia.org/wiki/B-tree

[2]: https://en.wikipedia.org/wiki/Locality_of_reference#Types_of...