How do you track monomorphization?

I’m not really sure if that’s a correct title/term but I have a project in Zig and I’m using a lot of meta-programming there, and I’m worried about some helpers get compiled again and again and if I could maybe refactor some of those into different patterns.

So what I’m worried about is what functions occupy the most space, so I can then have a look and maybe rethink those parts again. All I know is that the binary size went up considerably (13M) but it might be for a lot of okish reasons (bundled sqlite, httpz, libc, etc.)

Also, I think I saw some zig tool to measure that but I cannot find it anymore.

Simple things should be caught and deduplicated by LLVM.

Can you provide examples of what you think might cause problems?

Regardless, reducing monomorphisation is good for faster compile times and smaller binaries
It could go either way for performance, benchmark if you care about that.

I am mostly worried about the SQL-builder part GitHub - cztomsik/fridge: A small, batteries-included database library for Zig. and then maybe about the parsing/serialization in GitHub - cztomsik/tokamak: Web framework for Zig that leverages dependency injection for clean, modular application development.
(which is using std.json under the hood but for every kind of req/res pair)

One simple and useful tool is nm in combination with grep and wc

nm zig-out/bin/mything | rg myfunc | wc -l
51

Run it on the finally binary and look for monomorphized functions (e.g grepping anon)

The difference between release modes tend to be significant.

Is a good approach: dump LLVM IR to a text file, then grep for monomorphisatons.

tigerbeetle/src/copyhound.zig at 20b15e421c04bb32e7faa688456db4644f03c8c9 · tigerbeetle/tigerbeetle · GitHub Worked at some point, might suffer bit rot now.

@cryptocode nm seems to be what I was looking for, at least for some initial phase.

@matklad I will have a look in that too, thank you.