I m trying to understand the purpose behaviour of `~ cache p

Question

I m trying to understand the purpose behaviour of `~ cache pants named caches` Based on <https www pantsbuild org docs using pants in ci directories to cache> there s suggestion that it should cache tools PEXs However if I run a CI build with a full cache hit key = hash of all lock files on `named caches` and an empty `lmdb store` I still see a lot of lines like the following plus corresponding `Completed` For lint check ends up being ~20s of wall time spent building the pexes ```Starting Building isort pex from isort default lock Starting Building extra type stubs pex Starting Building mypy pex from 3rdparty python mypy lock Starting Building 59 requirements for requirements pex from the 3rdparty python default lock resolve Starting Building requirements venv pex``` For testing ends up being 2 5 minutes of wall time building pexes ```Starting Building 42 requirements for requirements pex from the 3rdparty python default lock resolve Starting Building pytest runner pex ``` I d be expecting that the ~2GB in `named caches` would eliminate the 3 minutes of building all these pexes even if nothing else is cached but that s apparently not the behaviour Is there something I may be doing wrong A few more details in the thread

broad-processor-92400 · Answer

I cannot see any significant difference in timing or output between the build above or one with an empty `named caches` too i e fresh `named caches` and `lmdb store` Cache key ```pants named $ runner os $ hashFiles pants toml $ hashFiles 3rdparty lock ``` The output above is from commands like ` pants lint check ` and ` pants test ` The output from ` stats log = true` includes info like ` ` comments mine ```Counters local cache requests cached 0 due to empty lmdb store presumably local store read blob size sum 14329918098 14GB suggests that some cache is being used but a build with empty named caches has a similar number``` pants version 2 13 0

witty-crayon-22786 · Answer

the primary interesting named cache is for PEX and the primary interesting subcomponent of that is of built wheels

witty-crayon-22786 · Answer

if your build uses mostly pre built wheels fetched from the network it s possible that re fetching them is cheaper for you

witty-crayon-22786 · Answer

the lmdb store caches complete process executions you either completely hit or completely miss for each process

witty-crayon-22786 · Answer

the named caches can partially accelerate something like a python resolve process by skipping some individual steps inside the process such as wheel builds

broad-processor-92400 · Answer

Hm okay I think our external dependencies are entirely bdist wheels so that seems to match with what you say

broad-processor-92400 · Answer

I think this suggests that it d be better for our CI to just not cache `named caches` at all because the time spent restoring saving it seems to be more than it saves

broad-processor-92400 · Answer

Oh I forgot to thank you for your insight yesterday sorry and thank you To confirm the behaviour is that the pex files referenced in these `Starting Building Completed Building ` lines are cached in `lmdb store` or in a remote cache if using rather than `named caches` even the tool ones using default lockfiles like black isort

witty-crayon-22786 · Answer

that s correct you can hit miss for the entire process using the `lmdb store` local or remote cache

cold-sugar-54376 · Answer

< broad processor 92400> were you able to have luck just by not caching `named caches` and only caching the `lmdb store`

broad-processor-92400 · Answer

yep I ve removed the named caches cache and that s saving us 30 45s in each CI build

witty-crayon-22786 · Answer

mm <https github com pantsbuild pants issues 14364> is also relevant here

cold-sugar-54376 · Answer

what keys do you end up caching on for lmdb store

broad-processor-92400 · Answer

Our key is `pants lmdb $ runner os $ hashFiles pants toml $ hashFiles BUILD $ hashFiles subdir ` and then we restore from truncated versions of that we re only using pants in `subdir` at the moment We re hoping to switch to a remote cache soon ish though