# Questions on delta base cache fetching

1 messages from 2019-11-23 to 2019-11-23. Participants: Matheus Tavares Bernardino.
Thread: https://gitlist.dev/t/52322

## Matheus Tavares Bernardino, 2019-11-23 19:54

Subject: Questions on delta base cache fetching
Message-ID: <CAHd-oW4gXSEsO7H0f-85vhWheUQ8CtGw5Jh7QP=h_inBpFTJDA@mail.gmail.com>
URL: https://gitlist.dev/e/CAHd-oW4gXSEsO7H0f-85vhWheUQ8CtGw5Jh7QP%3Dh_inBpFTJDA%40mail.gmail.com

```
Hi, everyone

A few questions popped into my head regarding unpacking functions that
fetch from the delta base cache. Their behavior on the cached entries
sometimes seemed a little counterintuitive for me, so I hoped you
could help me better understand.

1. If cache_or_unpack_entry() finds the desired object in cache, it
just retrieves and returns the entry, not updating its position in the
LRU list. Shouldn't it do so (possibly by removing and re-inserting
the entry)? Or maybe shouldn't the retrieval function itself do the
update?

2. While resolving a delta chain, unpack_entry() checks if the base is
in cache and removes it if so. At first, this seemed a little odd to
me, but the entry is re-inserted at phase 3. FWIU, this is done to
update the entry's position in the LRU list, is that right?

However, if the function is called to unpack a base object which is
already in cache, it will just remove the cache entry and don't
re-insert it (as it won't go through phase 3). Calling the
cache_or_unpack_entry() "wrapper", thought, will, in this case, return
the cache entry without removing it (nor calling unpack_entry()). To
avoid removing recently used entries from the cache, shouldn't
external callers, perhaps, always call the wrapper instead of
unpack_entry()?

Thanks,
Matheus

```