4 ms·

Yes, you understood that right. The existing executable file is not written completly anew. And yes, it will be faster. The way Zig does this is by only recomp

by ikskuh 6y ago

Yes, you understood that right. The existing executable file is not written completly anew. And yes, it will be faster. The way Zig does this is by only recompiling and modifying the parts of the executable where the source has changed. Imagine a project like chromium, where your executable is 150 MB large. Now you change a single function. Classic linking would require the whole linking process and the write of 150 MB of code. Zig will only compile and patch a single function (when lucky: less than 1kB) and emit this. Less I/O, less overall work to do.

tom_mellior 6y ago
> Now you change a single function. Classic linking would require the whole linking process and the write of 150 MB of code. Zig will only compile and patch a single function (when lucky: less than 1kB) and emit this. I see, thanks. I think I was misled by the article's "the final executable depends on everything else and so any meaningful change to the code will invalidate it". My understanding now is that, since the Zig compiler knows exactly what has changed, unlike a traditional linker it will not invalidate the parts that haven't changed. Is that correct?
- dnautics 6y ago
  > the final executable depends on everything else and so any meaningful change to the code will invalidate it If I'm not mistaken that refers to in traditional compiled languages.
rictic 6y ago
What if the machine code for the function is larger after than before? I guess even worst case, writing 151MB to disk is fast if you have the data ready. Very fast with a modern SSD.
- AndyKelley 6y ago
  This is a fascinating topic that I hope to follow up with a more technical blog post. The short summary is that there is room for functions to grow, and if they still exceed the padding, they get moved around to a new location in both virtual memory and in the file. Because of indirect function calls this means callsites remain the same; only the GOT entry has to get updated. The actual function body is moved with the copy_file_range syscall, where available.

by ikskuh 6y ago

tom_mellior 6y ago

> Now you change a single function. Classic linking would require the whole linking process and the write of 150 MB of code. Zig will only compile and patch a single function (when lucky: less than 1kB) and emit this. I see, thanks. I think I was misled by the article's "the final executable depends on everything else and so any meaningful change to the code will invalidate it". My understanding now is that, since the Zig compiler knows exactly what has changed, unlike a traditional linker it will not invalidate the parts that haven't changed. Is that correct?

dnautics 6y ago
> the final executable depends on everything else and so any meaningful change to the code will invalidate it If I'm not mistaken that refers to in traditional compiled languages.

rictic 6y ago

What if the machine code for the function is larger after than before? I guess even worst case, writing 151MB to disk is fast if you have the data ready. Very fast with a modern SSD.

AndyKelley 6y ago
This is a fascinating topic that I hope to follow up with a more technical blog post. The short summary is that there is room for functions to grow, and if they still exceed the padding, they get moved around to a new location in both virtual memory and in the file. Because of indirect function calls this means callsites remain the same; only the GOT entry has to get updated. The actual function body is moved with the copy_file_range syscall, where available.