[prof_hobart]

Most people have several stores for clothes (wardrobe/closet, wash basket, washing machine, in a basket waiting to make it back to the wardrobe etc) and depending how organised you are, the clothes you need could be in any of those on a given morning.

And in the wardrobe itself, I don't have enough separate shelves to be able to organise my clothes both by type and by purpose (so I've got sports socks, walking socks and work socks all in the same drawer for example). It can sometimes take several minutes to locate all of the clothes I actually want for a given day.

On days that I need to be out of the house particularly early, I will "cache" my next day's clothes by getting all of them ready the night before and putting them by the end of the bed, so that I've got instant access to them.

Similarly, I've got a cache of stuff that I need on a daily basis - keys, my wallet with some money and a single credit card in etc - on a shelf near the door, whereas the rest of my keys and the rest of my cards are grouped together somewhere else in the house.

I think it's this kind of stuff that the article is talking about.

[LoSboccacc]

I do have a chairdrobe for two use items like sweaters and pants.

[turaw]

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...

[prof_hobart]

> 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.

Except in emergencies. But I regularly need stuff from the "hanging on the clothes drier"/"in the basket ready to come upstairs"/"in a big pile on the end of the bed ready to be put in the wardrobe" ones.

> but it isn't caching as described in the article,

It's still caching. It's just a prefetch cache - using quiet time to prefetch my clothes for when they are needed very quickly.

> so excellent organization is (probably) the best way to cut down on overall time.

I'm not sure it is. Excellent organisation has quite a write-time overhead. In most cases, the amount of effort to organise everything perfectly is going to outweigh the fractional time saving I'd get on most mornings.

And in this case I'm also not looking to optimise overall time. I'm specifically looking to optimise speed to access it in the morning.

>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,

I would be. If I had to go and get my single credit card from the filing cabinet where I keep the rest of them, then go and get my work pass from a "work" pile, my keys from the key box, my coat from the closet, my shoes from the shoe cupboard, my bus pass from my transport drawer, my daughter's school bag from her school-related pile etc, etc.

The author makes it pretty clear that he's talking about caching in exactly this way

"Caching is such an obvious thing because we do it all the time. I mean, the amount of information I get . . . certain things I have to keep track of right now, a bunch of things I have on my desk, and then other things are filed away, and then eventually filed away into the university archives system where it takes a whole day to get stuff out of it if I wanted. But we use that technique all the time to try to organize our lives."

At the end of the day, it's never going to be a cache in the true computer sense of the work - there's not a separate copy being made (except in the case of my keys, where I've got exactly that, but that's more for failover than for caching) - but the idea of grouping things by speed of access in a given scenario rather than by category is analogous enough to caching to be worth discussing.

If you want to call it "locality of reference", that's fine (and the link even talks about caching as one form of it). But one critical factor of an analogy is that it's a reasonably well understood term, and I strongly suspect that a lot more people would understand cache than locality of reference.

[turaw]

Essentially, I agree with everything you said -- the core of my complaints about this book excerpt is that it seemed to confuse the areas of responsibility for caches (and their structures) and efficient storage data structures.

I do think that analogies should be less, for want of a better term, leaky than those presented in the article: if they hadn't dragged CS topics into the discussion, I would've upvoted a reasonable productivity article and left it at that.