我应该自己优化代码还是让编译器/gcc来做

我正在写一个c代码，我想知道，如果让乘法这样的简单操作对CPU更友好，是否会有什么不同，代码会更快。例如，替换这一行代码：

 y = x * 15;

与

---

y=x如今，手工优化代码几乎总是徒劳的，尤其是在高级语言中。虽然C几乎是汇编语言，但现代编译器内置的技巧比大多数人所知道的要多得多

此外，除非您正在优化的代码将被大量使用，即连续数百万次，否则优化代码的工作将花费比您节省的时间更多的时间

话虽如此，要想知道你的代码是否快得多，唯一的办法就是测试它：把每个版本放在一个紧密的循环中，执行一百万次（或更多），然后看看是否有明显的差异

请注意，您的优化是针对一个特定的乘法器进行的——您使用它的任何其他操作数都将产生不同的结果。因为它不能被推广，所以在任何情况下，这种优化都不太可能由任何编译器来完成——只看代码，不知道它将在什么处理器架构上运行，我不能说它是否会更快。
答案有两个部分：

不，除非您正在编写一个非常专门的函数（例如，必须在20个时钟中执行的信号处理函数），否则您不应该优化；那就交给编译器吧。一般来说，您的工作是编写可读的代码，编译器将（对其功能进行优化）。请注意，不同处理器的优化将不同，因为它们的硬件（计算能力）可能非常不同。例如，一条按N移位指令（如代码中的指令）在具有常规移位器的处理器上可能需要N个时钟，但在具有硬件桶形移位器的处理器上可能需要一个时钟（或更少）
是的，大多数现代优化编译器将在没有显式优化选项的情况下进行优化（例如，在适当的情况下通过移位替换乘法）
总而言之，只有在极少数情况下才进行优化，因为您已经知道编译器的性能不好，这是一个必须解决的问题，您很清楚如何比编译器做得更好，因此增加的维护成本是值得的。
您真的不知道。我猜不会，它不会优化这个，但我可能错了。只需编写代码，对其进行分析，并优化那些真正让你慢下来的部分。过早的优化会导致大量的问题。事实证明，GCC6.3优化了这一点（如果你通过了-O2）：总是：首先编写有效的代码，然后编写测试来测试你的代码（以及它的性能），然后进行优化。这保证了您的代码仍能正确执行，并且您的优化实际上提高了性能。一般来说，1）编写易于阅读/理解的代码2）优化在算法逻辑中最有用，不是像您建议的那样就地优化code@user3629249你的#1点非常好：高级语言正是为了做到这一点——编写易于理解的代码。为什么要投反对票？这个答案是不准确的还是有误导性的？
 y = x << 4;
 y -= x;