问题标签 [inlining]

Valentin Kuzub 评论了我对 SO 问题之一的回答，他认为 JIT 编译器内联属性将导致反射停止工作。

案例如下：

Fuzz函数接受 lambda 表达式并使用反射来查找属性。这是 MVC 在HtmlHelper扩展中的常见做法。

我认为即使Bar属性被内联，反射也不会停止工作，因为它是对它的调用Bar将被内联并且typeof(Foo).GetProperty("Bar")仍然会返回一个有效的PropertyInfo.

您能否确认一下，或者我对方法内联的理解是错误的？

我最近一直在写几节课；而且我想知道这是否是不好的做法，对性能不利，破坏封装，或者实际上在标头中定义一些较小的成员函数是否还有其他固有的坏处（我确实尝试过 Google！）。这是一个我用很多这样的标题编写的示例：

那么，像这样的内联函数真的有什么问题吗，或者可以接受吗？

（另外，我不确定这是否更适合“代码审查”网站）

在 c++ 中，什么是估计内联函数的计算时间优势的一个很好的启发式方法，特别是当函数被非常频繁地调用并且占程序执行时间的 >= 10% 时（例如，蛮力的评估函数或随机优化过程）。尽管内联最终可能超出我的控制范围，但我仍然很好奇。

我正在尝试强制内联成员函数，但出现错误：

这是提炼的产生错误的代码

我正在使用 Xcode / gcc

当一个在参数中带有指针的函数被内联时，编译器是否会在优化过程中删除间接？当然，当它有意义时..

这是一个明显的例子：

这种情况是微不足道的，但是如果编译器进行了优化，是否有一些情况不会？

奖励：我在哪里可以获得我的编译器所做的一些“基本”优化的列表？

ps：我只是好奇

背景

下面是一个用 C++ 编写的数值软件的关键循环，主要通过其中一个成员比较两个对象：

a并且b属于ASD：

我正在研究将此比较放在轻量级成员函数中的效果：

并像这样使用它：

编译器正在内联这个函数，但问题是，汇编代码会有所不同，并导致超过 10% 的运行时开销。我不得不质疑：

问题

1. 为什么编译器会产生不同的汇编代码？

2. 为什么生产的装配速度较慢？

编辑： 通过实施@KamyarSouri 的建议（j%16）已经回答了第二个问题。汇编代码现在看起来几乎相同（请参阅http://pastebin.com/diff.php?i=yqXedtPm）。唯一的区别是第 18、33、48 行：

材料

• 测试代码： http: //pastebin.com/03s3Kvry
• 带有 /Ox /Ob2 /Ot /arch:SSE2 的 MSVC10 上的程序集输出：
  • 编译器内联版本： http: //pastebin.com/yqXedtPm
  • 手动内联版本： http: //pastebin.com/pYSXL77f
  • 差异http://pastebin.com/diff.php?i=yqXedtPm

此图表显示了我的代码 50 次测试运行的 FLOP/s（最大比例因子）。

生成绘图的 gnuplot 脚本：http: //pastebin.com/8amNqya7

编译器选项：

/Zi /W3 /WX- /MP /Ox /Ob2 /Oi /Ot /Oy /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm- / EHsc /MT /GS- /Gy /arch:SSE2 /fp:precise /Zc:wchar_t /Zc:forScope /Gd /analyze-

链接器选项：/INCREMENTAL:NO “kernel32.lib” “user32.lib” “gdi32.lib” “winspool.lib” “comdlg32.lib” “advapi32.lib” “shell32.lib” “ole32.lib” “oleaut32. lib" "uuid.lib" "odbc32.lib" "odbccp32.lib" /ALLOWISOLATION /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /SUBSYSTEM:CONSOLE /OPT:REF /OPT:ICF /LTCG /TLBID :1 /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:QUEUE

一个方法可以被内联；有一个属性可以防止这种情况（“有一个属性”）。但是，由于 JITter 的尾调用优化（http://www.hanselman.com/blog/ReleaseISNOTDebug64bitOptimizationsAndCMethodInliningInReleaseBuildCallStacks.aspx），显然一个方法也可能无法在 x64 上获得自己的堆栈帧。这会影响 的行为MethodBase.GetCurrentMethod吗？

我能找到的讨论主要是关于内联的（什么时候有资格被 CLR 内联的方法？）。虽然这些讨论本身很有趣，但我的问题实际上是关于在什么情况下——如果有的话——MethodBase.GetCurrentMethod可以依赖于识别程序员发出调用的相同方法（例如，后期绑定到一个方法当前方法实际上是替代方法）。内联是一种MethodBase.GetCurrentMethod可能被愚弄的方式，但我想知道它是否是唯一的方式？

这个问题说明了一切。我在看Can a recursive function be inline? 所以试图将其与Java相关联。

我试图了解 llvm 内联如何工作（内联类）。我不明白的操作如下：

当 SmallVector 是 llvm 类时。特别是我不明白这段代码中“16”的功能是什么..

我正在使用 Linux 中的 gcc 在 C 中进行开发。

我正在按以下方式在 .H 和 .C 文件中组织我的小功能

这些函数很小，因此它们是内联的非常好的候选者，但我不知道它们是否会确定。

我对我组织文件的方式有疑问，我认为将我的所有函数直接内联到没有 .C 文件的 .h 文件中可能会更好。你能帮我澄清一下我的疑问吗？