Garbage collection for cache directory

[aomarks]

The .wireit/<script>/cache directory currently can grow indefinitely. We should implement a garbage collection strategy to cap the size of this directory.

An LRU cache with a configurable maximum number of entries seems like what we want.

We will want to make sure we have an efficient way to maintain the cache hit rate data which scales well with the size of the cache. We will probably want some kind of on-disk index file that lets us read/write cache hit rates efficiently, to determine which cache entry needs to be deleted when the cap is hit. A doubly-linked-list implemented in the filesystem itself with symlinks (or just files containing SHAs) could also be an interesting way to do this.

[joshkraft]

Hi @aomarks - this issue piqued my curiosity. I am wondering what the current status is? I'm interested in giving it a shot, but it has been sitting for awhile so I figured I would check before digging in.

[aomarks]

Hi @joshkraft! Contributions would be more than welcome.

Lately I've been wondering if local caching is something we really want in general. One thing it's nice for is when switching back and forth between git branches, or undos. But I'm not sure the complexity and additional latency of maintaining the local cache is worthwhile. What do you think? Have you been relying on local caching? Did you find that the cache folder was getting too big?

[joshkraft]

That is a great question. I actually just started using wireit, so unfortunately I have no real opinion on the utility of the local caching.

If the goal is keeping additional complexity/latency low, one interesting approach I noticed in another project is to inject some randomness into the process. Rather than keeping track of every get/put to the cache, each execution calls a random() function that returns true 1%/5%/etc. of the time. If it returns true, kick off a 'cache cleaning' process.

Cache cleaning could be done in a number of ways:

• delete random cache entries until we are beneath the desired limit (could also consider the 2-random approach)
• delete oldest cache entries (based on stats.mtimeMs) until we are beneath the desired limit
• delete all cache entries that are older than some time (could be user defined)

I am curious if you think this approach would be a good fit here? I'm happy to do some experimentation and see what it would look like in this project.

[joshkraft]

Hi @aomarks,

I've had a chance to start using Wireit personally and I have found local caching to be useful, as someone who is a serial branch switcher.

I did some POC work implementing a few different eviction mechanisms. My guess is that the additional latency introduced here would largely be driven by the time it takes to delete evicted entries from the cache. I'm curious if you have suggestions on some parameters I can use to benchmark the different approaches? For example:

1. What would be a reasonable cache limit to default to? 100, 1000?

2. What might a 'practical worst-case scenario' output folder look like? Interested in size, structure, etc.

Also, feel free to let me know if adding this functionality doesn't align with the project's goals. I'm happy to investigate some options and report back with benchmarking results, but if the value added here isn't worth the added complexity I'm happy to direct my effort towards another issue.

[Westbrook]

How is the mangement of the default cache and the cache that GitHub Actions might you different currently? In particular, I'm leveraging CircleCI, for which I actually turn off the default CI cache mechanism, because I couldn't get it to actually build/save a cache in that context, however that cache does grow indefintiely. Is there something about the GH Actions cache approach that could be leveraged in "local" mode? If not, then raising the priority of this issue would be really nice to see and support expanded consumption of Wireit across projects I work with at Adobe.