We could save petabytes of cache storage with Zstandard and Pingora

I've never been entirely sure how it works, whether it only does particular things when clobbering an existing file or does some other heuristic to make it more likely that changing one function in the middle of the archive requires only a small part of it to need to be transferred instead of every byte from that point onward.

It's definitely possible to optimize the rlib format, like representing generic types as a tree of short IDs instead of a string or separating them into an optional debug file. Or do it like Zig with a new IR designed to be compact and easy to assemble into final executables. Even a simple global cache for the times you get lucky and end up with the same hash could help.

The problem is no one on the core team has time to do it because they are always overworked from the amount of bugs that need fixing. They also have a culture of making sure all changes are perfect before they go stable as a overreaction to C++ shipping half baked proposals. I think these are the reasons everything is moving so slow.

It had the nice effect that whoever caused the headers to need to be recompiled was the only one who had to pay the recompilation tax instead of everyone.

You may be cleaving the problem along the wrong plane if you're worried about sharing between multiple projects on the same machine versus across all of the members of a single team.

Artifactory is older than dirt. And its main feature isn't even saving bandwidth, it's ensuring that versioned libraries can never be overwritten in place with a different version potentially containing a trojan. And it can be set up not to download new versions until they've survived long enough for someone to hopefully notice a supply chain attack.

It was part of the (now defunct) frea project: https://freajs.github.io/frea-website/

> Transcoding does not mean compressing everything. Images, video, and fonts are usually compressed already.

It's because they're already lossily compressed that, precisely, they're the typical targets for transcoding.

EDIT: oops, wrote lossless instead of lossy, sorry about that

You could split the file into independently compressed blocks as well. But that'd reduce compression rate and require adding some kind of index for seeking.

Or they have an upper size limit for the file size they compress, since large files are rarely compressible text.

In any case it is something that needs the be handled before going live with a compressed cache. But the article sounds like they simply didn't implement compressed caching for those cases, which makes no sense.

Given how fast zstd can decompress, this may or may not actually be a win: the time spent waiting for I/O might be so large that the decompression can fit within the wait time.

Turns out we can squeeze quite a bit more compression performance out of DEFLATE - ~10x in certain instances, 2x as a base minimum (read the paper for details).

[1]: https://github.com/thammegowda/pigzpp

[2]: https://arxiv.org/abs/2608.24153

They also don't always support window sizes above 8MB which means levels above 19 can fail to decompress (if they use the more than 8MB of window).

The compression cost is always the same. The storage cost depends on how long you keep something in cache. The decode cost is proportional to number of total hits.

So compression makes the most sense for something you want to keep a long time that will be accessed very rarely. And the least sense for something you will drop very soon and will have many people requesting it.