什么时候应该使用__forceinline而不是inline? [英] When should I use __forceinline instead of inline?

问题描述

Visual Studio包含对__forceinline的支持. Microsoft Visual Studio 2005文档指出:

Visual Studio includes support for __forceinline. The Microsoft Visual Studio 2005 documentation states:

__ forceinline关键字将覆盖 成本/效益分析及依据 根据程序员的判断 代替.

The __forceinline keyword overrides the cost/benefit analysis and relies on the judgment of the programmer instead.

这引发了一个问题:编译器的成本/收益分析何时出错?而且，我应该怎么知道这是错误的呢?

This raises the question: When is the compiler's cost/benefit analysis wrong? And, how am I supposed to know that it's wrong?

在什么情况下假设我比我的编译器对此问题更了解?

In what scenario is it assumed that I know better than my compiler on this issue?

推荐答案

编译器基于静态代码分析来做出决策，而如果您按照don所说的那样进行分析，则您将进行动态分析，其范围可能会更广.特定代码段的调用次数通常在很大程度上取决于使用它的上下文，例如数据.对一组典型的用例进行概要分析可以做到这一点.我个人通过在自动回归测试中启用概要分析来收集此信息.除了强制内联之外，我还展开了循环，并根据这些数据进行了其他手动优化，以达到良好的效果.之后也必须再次进行概要分析，因为有时您的最大努力实际上可能导致性能下降.再次，自动化使痛苦减轻了很多.

The compiler is making its decisions based on static code analysis, whereas if you profile as don says, you are carrying out a dynamic analysis that can be much farther reaching. The number of calls to a specific piece of code is often largely determined by the context in which it is used, e.g. the data. Profiling a typical set of use cases will do this. Personally, I gather this information by enabling profiling on my automated regression tests. In addition to forcing inlines, I have unrolled loops and carried out other manual optimizations on the basis of such data, to good effect. It is also imperative to profile again afterwards, as sometimes your best efforts can actually lead to decreased performance. Again, automation makes this a lot less painful.

以我的经验，调整alogorithms通常比直接代码优化要好得多.

More often than not though, in my experience, tweaking alogorithms gives much better results than straight code optimization.

这篇关于什么时候应该使用__forceinline而不是inline?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！