为什么不优化可执行文件中的填充字节？

如何解决为什么不优化可执行文件中的填充字节？

当我创建一个小的 Mac Mach-O 可执行文件时，例如用 C 编写的“Hello World”，由于对齐填充，它的大小约为 48k。但与此同时，我可以在 .bss 部分定义 100k 个零（例如，通过指定 100k 个字符的静态数组），并且它只向磁盘上的可执行文件添加几个字节。

我想知道为什么 padding(，我想它只在加载后起作用) 也没有以某种方式“打包”。

解决方法

您似乎没有意识到填充的作用：确保对象的大小满足约束条件，例如是特定数字的倍数。填充字节的值通常并不重要，但它们的存在是必不可少的。

分配给 ELF（例如）.bss 部分的对象的情况恰恰相反：它们的值很重要，但它们的大小不需要通过它们的磁盘表示来反映。此外，这些对象的值只是通过将它们分配给 .bss 的事实来确定的，因此实际上，每个对象在二进制文件中消耗 O(1) 空间（相对于其内存表示的大小）。

附录： 可以想象，可以设计一种二进制格式来携带压缩数据，以便这种填充确实在磁盘上被压缩。人们只能推测为什么这种格式不受欢迎，但我认为至少有一部分答案是，未压缩二进制格式的简单性和加载速度比相对较少的空间节省更有价值。压缩格式可以实现。