代码优化

Question

如果我有一个大的结构(有很多成员变量)。此结构指针在我的代码中传递给许多函数。这种结构的一些成员变量在几乎所有函数中都经常使用。

1. 如果我将那些经常使用的成员变量放在结构声明的开头，它会对MCPS -百万次/秒(代码消耗的时间)的代码进行优化吗？如果我把经常访问的成员放在时间上，他们会被有效地访问/比他们被随机地放在结构声明底部的结构中的时间更短吗？如果是的话，逻辑是什么？
2. 如果在某些函数中访问了一个结构成员，如下所示： 结构pointer1->成员变量

如果我将它分配给一个局部变量，然后访问局部变量(如下面所示)，它会在MCPS方面帮助优化它吗？

local_variable = structurepointer1->member_variable;

如果是，那又有什么用呢？

Answer 1

1)字段在结构中的位置不应影响其访问时间，但如果您的结构非常大且跨多个页面，则最好将经常在快速连续使用的成员紧密地放置在一起，以增加引用的局部性，并尽量减少缓存丢失。

( 2)可能/可能不是。事实上，这可能会使事情变慢。如果变量不是易失性的，则编译器可能足够聪明地将字段存储在寄存器中。即使没有，您的处理器也会缓存它的值，但是如果is的使用与其他内存访问之间有很大的距离，这可能于事无补。如果该值可能存储在寄存器中或留在处理器的缓存中，那么将其分配给本地只会是不必要的额外工作。

标准优化免责声明:优化前始终配置文件。确保你想优化的东西是值得优化的。始终分析您尝试的优化，并确保它们实际上使事情更快(而不是更慢)。

Answer 2

首先，强制性的免责声明:对于所有的性能问题，您必须对代码进行概要分析，以查看哪些地方可以进行改进。

不过，通常情况下，任何可以将数据保存在处理器缓存中的操作都会有所帮助。将最常见的访问项目紧密地放在一起将有助于这一点。

Answer 3

我知道这并不是真正回答您的问题，但是在您深入研究超级优化您的代码之前，请先看看这个演示文稿http://dl.fefe.de/optimizer-isec.pdf。我在现场看到了它，这是一个很好的开场白，它显示编译器在优化方面比我们想象的要先进得多，而且可读的代码比小的优化更重要。

对于2，最好不要声明局部变量。编译器通常足够聪明，能够确定何时以及如何使用变量，并利用寄存器来保持其运行。

此外，我还会支持making的建议，在假设瓶颈之前分析代码。