Question

我经常使用引用来简化代码的外观：

vec3f& vertex = _vertices[index];

// Calculate the vertex position
vertex[0] = startx + col * colWidth;
vertex[1] = starty + row * rowWidth;
vertex[2] = 0.0f;

编译器是否会识别并优化它，因此基本上是以下几种？

_vertices[index][0] = startx + col * colWidth;
_vertices[index][1] = starty + row * rowWidth;
_vertices[index][2] = 0.0f;

Answer 1

是。这是任何现代（甚至是古老）编译器都将进行的基本优化。

事实上，我认为你编写一个优化是不正确的，因为将它转换为汇编的直接转换方式涉及到_vertex地址的存储，加上索引，再加上{0,1 ，2}（当然，乘以适当的大小）。

总的来说，现代编译器是惊人的。几乎所有你能想到的优化都将得到实施。您应始终以强调可读性的方式编写代码，除非您知道某种方式对代码具有显着的性能优势。

作为一个简单的例子，代码如下：

int func() {
    int x;
    int y;
    int z;
    int a;

    x = 5*5;
    y = x;
    z = y;
    a = 100 * 100 * 100* 100;

    return z;
}

将针对此进行优化：

int func() {
    return 25
}

此外，编译器还将内联函数，以便不实际调用。相反，出现'func（）'的地方只会被'25'取代。

这只是一个简单的例子。现代编译器实现了许多更复杂的优化。

Answer 2

编译器甚至可以做更聪明的事情。也许他们会做的

vec3f * vertex = _vertices[index];

*vertex++ = startx + col * colWidth;
*vertex++ = starty + row * rowWidth;
*vertex++ = 0.0f;

甚至其他变化...

Answer 3

根据变量的类型，您所描述的是悲观。

如果vertices是类类型，那么您的原始表单只会调用operator[]并重新使用返回的引用。你的第二个表格会分三个电话。不一定可以推断返回的引用每次都会引用同一个对象。

与原始vertices对象中的重复查找相比，引用的成本可能不重要。

除了在有限的情况下，编译器不能优化（或悲观）额外的函数调用，除非引入的更改不能被符合程序检测到。通常，这需要内联定义的可见性。

这被称为“似乎”规则。只要代码行为就像一样，语言规则已经完全遵循，实现可以进行任何它认为合适的优化。

编译器优化参考

3 个答案: