Discussion on: Analysis of the overhead of a minimal Zig program

ernest0x profile image
Petros Moisiadis

The entire article is based on a program that does nothing. Compilers are meant to be used to compile useful programs that actually do things. Programs that use arguments, environmental variables, etc. So, any overhead to handle what useful programs are doing most of the time is often more than acceptable. For TLS initialization, there could be an option to disable it, but the overhead is still acceptable for many cases.

The first of the three points mentioned at the end is about a program's initialization performance. Most of the time this can be neglected as it is not significant in relation to the whole performance of a program. E.g. when programs run as services. Even if a program is re-spawned very frequently, overhead from system calls involved to create new processes, terminate old ones, etc., could be more significant. Besides, in that case, it makes more sense to look at the architecture of the whole stack than blame your compiler's ability to create smaller binaries.

The second point is about people being impressed when looking at the size of the produced binaries. Binaries produced by zig compiler are pretty small already and on par with C. With today's hardware, it is not a big deal to make it even smaller. There are many other features of Zig for people to be impressed with.

About the third point, I would agree that developers should think carefully about how their program is using system resources, but this is true with writing programs in any language and has nothing to do with how a compiler implementation optimizes the code for using less resources. For most programmers, compilers are mostly a black box. Any optimization in any compiler implementation is meant to be taken as a bonus. So, a compiler that produces the tiniest possible binaries does not teach the programmers how to think wisely about resource usage. The programmers just take advantage of this ability and their programs can use less resources at initialization. But this difference, with today's hardware, could be insignificant. On the other hand, there are cases in which it makes sense to have bigger, statically linked binaries like Go and Rust compilers produce by default (at least when linking with other libs written in Go or Rust accordingly).