Hi. I recently started coding in Zig, and I love the language. However, recently (since version 0.16.0), due to the introduction of the “Io” interface, the size of a typical console “Hello, World!” has grown significantly. (About 470 KB with “-Doptimize=ReleaseSmall” and all possible optimizations in build.zig enabled.) This is happening for obvious reasons. Io entails a vtable with over 100+ functions, and this raises the question: will this issue be resolved in the future? Because, as a recent user who coded on version 0.15.2, I really liked the small binary sizes.
1 Like
7 Likes
My chess engine grew 300 kb (releasefast) with zig 0.16
Don’t know why and where.
Will it be fixed before 0.17.0 is released or is it not a priority right now?
I wouldn’t bet on it landing in 17. It’s not tagged as something that would block the release of 17 (“urgent” doesn’t really mean what the tag name might lead you to think). 17 was initially supposed to be little more than an LLVM version upgrade, but the inevitable creep has been happening.
What’s important changes day by day based on progress and new information. Zig is not schedule-driven. I find “when” questions rarely provide answers that you can use for planning. For a particular issue, you can live with it, or if it’s a blocker, wait until it’s fixed. The issue is definitely acknowledged as important to fix.
3 Likes
Personally I noticed inconsistent binary size increases with 0.16,
I think on windows it became ~1-200kb but on linux it was >1MB (IIRC maybe even >2MB).
- it will be fixed eventually
- people use this metric as a heuristic for whether they will be able to achieve small binaries where it counts such as in embedded or webassembly. in those places nothing has regressed, in fact binary size has only decreased there.
12 Likes
Curious - if you have a wasm binary that uses Io, would that be expected to shrink even more once the larger solution is complete ?
It would be nice to get to a point where ReleaseSmall for wasm was optimised enough so that additional tools such as binaryen are not needed.
There is not an Io implementation that supports wasm (well Io.Threaded.init_single_threaded might?)
And that’s the secret, Io just isn’t implemented for these memory constrained platforms (exception embedded Linux I guess).
But that is fine since often you don’t want or need such a high level abstraction in such environments anyway, and if you do, well by the time they are implemented this issue should mostly be resolved.
There is also the option of implementing one yourself if you need to, which can ofc only include what you need and nothing else which should not have much impact on binary sizes.
1 Like
The journey to where it counts starts at hello world. People need to be persuaded that Zig is a good language for lean-and-mean embedded programming before they would actually commit their time. First impression matters like it or not. As things stand it’s a bad look.
1 Like
Sounds like we are in agreement
Ah yes, fair call.
I’m currently using an Io.Writer in wasm, and assuming the Io implementation is single_threaded, so that would be dragging a large vtable across with it ?
I haven’t done a deep dive on this yet, because I’m nowhere near done to the point where I need to worry about binary size yet.