我刚刚测试了一个我正在工作的程序，当我使用 -g 编译它时，我发现它的执行速度提高了 3μs（统计上显着的变化）。这对我来说毫无意义——我认为 -g 标志不应该影响程序的执行，即使它影响了程序的执行，它也会让它运行得更慢，而不是更快。
谁能告诉我为什么会这样？它是否会改变程序的执行流程？我没有使用 -O 进行编译，因为我需要它完全按照编写的方式执行，但是如果 -g 可以通过更改指令顺序以某种方式使其运行得更快，我显然应该使用它。
所以我需要确切地知道 -g 标志对程序所做的更改。
编辑：我运行的测试越多，t 值就越大（= 差异在统计上越显着）。这绝对不是测量错误——有些事情正在发生。
正如其他人所说，除非编译器中存在（不太可能的）错误，否则调试符号不会改变代码的控制流。
但是，它改变了执行，因为可执行文件变得更大，并且执行的代码在更多页面上分布得更广泛。您可以期待更多的缓存未命中和 IO 信号。在多任务环境中（甚至 Linux/busybox 系统也是这样），这可能会导致调度行为略有不同。
另一方面，测量您所描述的如此微小的时差本身就是一门艺术。您可能处于 Heisenberg 环境中，您的测量结果会影响执行时间。您的测量结果可能会显示出统计学上的显着偏差，但我会非常小心地将它们解释为这样那样的选项可以使代码更快。
-g 标志对实际生成的代码进行 0 次更改。它所做的是将调试部分添加到可执行文件中。这些部分不会在运行时加载，但调试器可以加载它们。由于现在的可执行文件有点不同，它更大 - 您可以尝试测量编号。在一个版本与另一个版本之间发生页面错误时，可执行文件在磁盘上的存储方式将会发生变化，但代码不会发生变化。
如果要查看程序集，请在二进制文件上运行 objdump -d 并进行比较
我确实质疑 3us 增加的有效性，可靠地测量 3us，至少在通用操作系统上是一项艰巨的任务 - 我希望你已经运行你的程序几千次（可能是几十万次）来用这个数字试图消除影响这种测量的所有随机因素。
当我在其中一个子例程上使用 -debug 和 -g 标志时，我的代码得到了不同的答案，所以虽然我不知道为什么，但它肯定会影响程序执行。