我对代码进行了剖析，发现一个内联函数占用了大约8%的样本。该函数是将矩阵下标转换为索引的函数。它很像Matlab中的sub2ind函数。
inline int sub2ind(const int sub_height, const int sub_width, const int width) {
return sub_height * width + sub_width;
}
我猜编译器没有执行内联扩展，但我不知道如何检查。
有什么方法可以改进吗？或明确让编译器执行内联扩展？
你确定编译时开启了优化吗？某些编译器有一个属性可以强制内联，即使编译器不想这样做：请参见此问题。
但它可能已经这样做了；您可以尝试让编译器输出汇编代码，并通过这种方式确认。
索引计算可能是您时间的重要部分--例如，如果您的算法是从矩阵中读取、进行少量计算，然后写回，那么索引计算确实是您计算时间的重要部分。
或者，您以一种编译器无法证明width在循环中始终保持不变的方式编写了代码，因此每次都必须重新从内存中读取它，以确保。尝试将width复制到本地变量并在内部循环中使用它。
现在，您已经说过这占用了您8%的时间--这意味着您可能无法获得超过8%的性能改进，而且可能更少。如果这真的很值得，那么该做的事情可能是根本改变如何遍历数组。
例如：
width是编译时常量，则可以将其明确设置为模板参数，您的编译器可能能够使用更聪明的方法进行乘法。*：您可能会做一些愚蠢的事情，比如将矩阵的数据结构放在存储矩阵条目的内存中！因此，当您更新矩阵时，可能会更改宽度。编译器必须防范这些漏洞，因此无法进行“明显应该”能够进行的优化。有时候，在另一种情况下，漏洞的一种可能是程序员的明显意图。总的来说，这些类型的漏洞往往无处不在，编译器比人更擅长发现这些漏洞。
width）保持不变，但是sub_height和sub_width在循环中会发生变化。 - ZHOUsub2ind(x, y, mymatrix.width());，并且编译器没有绝对证明存储宽度的内存位置没有被更改的方法（例如，因为没有任何东西否认您决定从存储宽度的内存地址开始存储矩阵内容，所以mymatrix[0] = 1;会改变宽度），那么它必须编写检查宽度更改的代码。 - user1084944inline int sub2ind(const int sub_height, const int sub_width, const int width) {
return sub_height * width + sub_width;
}
int main() {
volatile int n[] = {1, 2, 3};
return sub2ind(n[0], n[1], n[2]);
}
如果没有进行优化编译 (g++ -S test.cc)，则得到的代码中sub2ind没有被嵌入:
main:
.LFB1:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $32, %rsp
movl $1, -16(%rbp)
movl $2, -12(%rbp)
movl $3, -8(%rbp)
movq -16(%rbp), %rax
movq %rax, -32(%rbp)
movl -8(%rbp), %eax
movl %eax, -24(%rbp)
movl -24(%rbp), %edx
movl -28(%rbp), %ecx
movl -32(%rbp), %eax
movl %ecx, %esi
movl %eax, %edi
call _Z7sub2indiii ; call to sub2ind
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
使用优化编译(g++ -S -O3 test.cc)会导致sub2ind被内联，大部分被优化掉:
main:
.LFB1:
.cfi_startproc
movl $1, -24(%rsp)
movl $2, -20(%rsp)
movq -24(%rsp), %rax
movl $3, -16(%rsp)
movq %rax, -40(%rsp)
movl $3, -32(%rsp)
movl -32(%rsp), %eax
movl -36(%rsp), %edx
movl -40(%rsp), %ecx
imull %ecx, %eax
addl %edx, %eax
ret
.cfi_endproc
如果您确信函数未被内联，请先确保在编译器选项中启用了优化。