In a sample size of 1 this makes the example in #7276 not crash node when calling it with --max-old-space-size=500

_contentLength is 0 when revalidating the cache with new content. This needs to be fixed before we can trust _contentLength.

Packument size to memory ratio (units are 1000 not 1024):

44.19% | [mean contentLength < 10k]
46.89% | [median contentLength < 10k]
61.59% | [mean contentLength < 1M]
60.48% | [median contentLength < 1M]
74.53% | [mean contentLength > 1M]
80.35% | [median contentLength > 1M]

The current tradeoff here is that we are swapping memory for disk reads (the cache reads from disk). On modern machines with large amounts of memory this is likely not a very big tradeoff, most high-memory high-end systems use ssd disks. This is more impactful of low memory systems, where running out of memory means the process dies.

I suggest an initial limit of 1M for the maximum packument we'll put in the cache, and then we use a multiplier of .6 for all packuments when reporting their size to lru-cache. This will over-report smaller packuments in favor of not accidentally under reporting medium sized ones an accidentally going further over the desired memory usage.

I don't have a good way to calculate what percentage of the heap_size_limit we should allow this cache to use. Again this is a memory/disk read tradeoff. Perhaps conservatively limiting the lru cache is best here.

This is ready for tweaking based on your findings @wraithgar. I was able to get all the tests passing with the new packument cache in place. The only changes were to logging and a few tests with the mock-registry needed times: N to be set since packuments aren't cached as aggressively as before.

@wraithgar Approved and ready to land I think. Can you squash with an appropriate body message that closes #7276?

npm/pacote#369 is still an issue but this doesn't make that issue any worse so it shouldn't block this PR

Here is the research used to calculate the multipliers.

packument size profiling.xlsx

The current tradeoff here is that we are swapping memory for disk reads (the cache reads from disk)

We could of course also try to increase the default node memory limit? Or is that a bad idea.

We could of course also try to increase the default node memory limit? Or is that a bad idea.

That's up to you. This was built to react to that value, so scaling it would mean npm using more memory in this cache. It would take doing some benchmarking but I suspect that on modern systems w/ lots of memory and ssd drives the tradeoff isn't very large.