I just had to delete the cache after it ate 146GB of my disk-space, and this is from working on the same project for about a week.
Is there a way to prevent the zig cache from blowing up, this fast?
Tips will be appreciated.
1 Like
The size grows faster with your executable size, so the best way to reduce its growth rate is by reducing size of it.
I personally just delete it at the end of every day / when i feel like it.
There is no negativum to deleting it, if you dont mind building once from scratch and are not frequently revisitting drastically diferent builds. (like different build modes etc.)
1 Like
Finally a challenger to docker’s cache
5 Likes
I am unaware of any way to prevent its growth. It is influenced by the code you write, and altering the way I code for a the sake of a cache is a not something I am going to compromise on.
As for “dealing with it”, I personally created a simple shell script that gets executed by the window manager upon startup to delete any .zig-cache directory found under where I store my projects. It was a Temporary™ hack that has been working fine for a year now.
#!/usr/bin/env bash
find "$HOME/projects" -type d -name '.zig-cache' -exec rm -rf {} +
rm -rf "$XDG_CACHE_HOME/zig"
It could easily be adapted to a systemd service or equivalent if that is one’s preference.
1 Like
You could consider setting up your project such that it produces multiple smaller binary artifacts that can be cached independently and which load each other at runtime, instead of building one humongous executable that contains everything, at least for development/debug builds.
Instead of using @embedFile() to embed large assets like textures and audio into the executable, install them as regular files along the executable and load them at runtime. And instead of building and linking with large C library dependencies statically, build and link with them as dynamic libraries.
As a concrete example, if I set up my simple breakout game to build/link with SDL3 statically, build the project once (debug build), and then make some trivial modifications (changing a single letter in a std.debug.print() statement) 10 times, I end up with a .zig-cache that is ~360 MiB in size. If I repeat the process but this time instead build/link with SDL3 dynamically, it only reaches ~170 MiB.
But I still think the most practical and pragmatic approach is to just clear your caches every now and then, and hold out hope that some kind of automatic cache eviction is added to the compiler/build system further down the road.
3 Likes
What works nicely for me is to call a cleanup script from .git/hooks/post-commit
That sort of solves the “every now and then” without remembering or scheduling.
My cleanup bash script just checks the size of .zig-cache and if it’s above some sensible limit, .zig-cache is nuked
The script also prints a message when eviction happens, and the current size of the cache if not
Example output:
$ git commit -m'Reworking the ast'
.zig-cache is under 500MB (size: 54MB)
[main d229ea0d] Reworking the ast
1 file changed, 1 insertion(+), 1 deletion(-)
This may not work for projects where the cache grows very fast, or you commit rarely, but thought I’d mention it as it seems to work well.
3 Likes
Can you share your post commit hook? I’d like to steal borrow it.
1 Like
I have an elaborate hook that does other things as well, but here’s a simplified version (only tested on macOS): https://zigbin.io/141ce2
Just adjust the MB limit to your liking and paste that script straight into .git/hooks/post-commit
4 Likes