Memory timing

Memory timing

So - as we’ve seen, the data our program will use needs to have a defined type and size. Zig needs to know that. There’s one more thing it might also know about that data: its contents.

If Zig also knows the content of a piece of data, that means it’s known at compile time.

If the content can’t be known from the start of the program, then it’s data that’s only known at runtime.

Both the stack and the heap are part of runtime memory, and these “timing” concepts help us understand how and when each area is used:

• If the content is known at compile time, it is included in the binary.
• If it’s only known at runtime but is small and fixed, it goes on the stack.
• If it’s known at runtime but is large or variable, it goes on the heap.

When we define a string like this:

We’ve defined the type ([]const u8), and Zig can infer the size thanks to the assigned literal, and it also knows the exact content. It’s clearly a compile-time value.

But if we define and then change a number like this:

The variable n_x has been modified by an instruction. And in this case, that instruction, even though it’s a very simple operation, is enough to make n_x a value only known when the program runs, so it’s a runtime value.

All this doesn’t really matter much in a simple case like incrementing a variable. When we use functions to work with data, especially when the data types become more complex, it matters. We need to be more careful with memory, the more complicated they are.

And that’s one of Zig’s core principles:

• No hidden memory allocations

        In Zig, we have full and explicit control over how memory is managed. That control does come with a big responsibility: knowing how to manage it properly. But actually, it’s not that complicated if we understand a few key guidelines.