过度内联 [英] Excessive Inlining
问题描述
在内联小方法时应该多么明智。
我曾经读过，一般来说，大多数编译只会内联''一个'
等级。
IE：如果所有以下方法都被声明/定义为
各自的类内联，我可以期望编译器尝试并内联
他们都是？
obj.GetSize（）
{
a.GetLen（）
{
b.GetHead（）;
{
c.CreateIterator（）;
如果这在视觉上难以理解，我很抱歉。我只是试图将
描述为代码将被逻辑复制并嵌入到
连续级别的调用堆栈中。
< offtopic>
如果我更擅长GDB或Visual Studio - 我更愿意看看
得到的ASSEMBLY亲眼看看它做了什么。也许我可以
在DEBUG模式下执行应用程序并打开反汇编窗口 - 但是
会跳转到方法声明吗？我不像我希望的那样轻松调试调试器的成本。建议或一般规则？
< / offtopic>
从理论上讲，我为一个库编写了一个包装类
基本上由''传递''调用组成。
IE：我已经在一组C库调用上创建了一个C ++类接口。
struct GuiHelper
{
inline void SetWindowPos（int，int，int，int）
{
:: SetWindowPos（...）;
}
}
我很担心（每个我似乎记得那篇文章，如果我在我的其他函数中使用这些方法中的任何一种 - 我将使用
我的每个函数堆栈的内联调用。换句话说，如果我在其他内联调用中使用
这些方法，编译器何时会倾向于最终退出内联？
那么，在数量上，明智的内联是否重要？或者我可以willy
nilly声明/定义所有非常小的紧密方法作为内联并且
相信几个小的内联方法互相调用
很可能都是内联的。
- 注意：这也适用于Setters和Getters。我害怕
提供getX或getY方法，因为担心它们会在任何地方使用它们 - 它们会耗尽内联编译器的一级内容/>
创建 - 因此，可能不是最好的堆栈方法
内联。
提前感谢任何见解，
-Luther
LuB写道：
在内联小方法时应该多么明智。
请记住，内联只是对编译器的一个暗示。编译器
可以自由选择内联或不内联指定的
子程序。
如果你的分析表明内联子程序可以显着提高应用程序性能，考虑添加内联声明。
Fei
3月30日上午11点42分，刘飞< fei ... @ aepnetworks.com写道：
LuB写道：
在内联小方法时应该多么明智。
请记住，内联只是对编译器的一个提示。编译器
可以自由选择内联或不内联指定的
子程序。
如果你的分析表明内联子程序可以显着提高应用程序性能，考虑添加内联声明。
Fei
是的，我知道这只是一个提示。
假设我正在为其他人写一个图书馆。
然后，依次假设我的课程，结束其他一些图书馆（MFC，WTL，
拿你的选择）。我基本上是把一些图书馆包起来......写作
通过电话......然后将结果课程交给某人
else。也许卖给别人。
我是否会伤害别人的代码 - 通过声明和实施
作为内联所有简单的，一行都通过我的
库中的操作。
-Luther
LuB写道：
3月30日上午11点42分，刘飞< fei ... @ aepnetworks.comwrote：
< blockquote class =post_quotes>
> LuB写道：
>>在内联小方法时应该多么明智。
请记住，内联只是对编译器的一个提示。编译器可以自由选择内联或不内联指定的子程序。
如果您的分析表明内联子程序可以显着提高应用程序性能，考虑添加''inline''声明。
Fei
是的，我知道这只是一个暗示。
假设我正在为其他人编写一个库。
然后，依次假设我的课程，结束其他一些库（MFC，WTL，
随你选择）。我基本上是把一些图书馆包起来......写作
通过电话......然后将结果课程交给某人
else。也许卖给别人。
我是否会伤害别人的代码 - 通过声明和实施
作为内联所有简单的，一行都通过我的
库中的操作。
-Luther
它怎么会伤害别人的代码？内联只发生在链接
time ...是什么让你觉得它可能会伤害别人的代码？
How judicious ought one be when inlining small methods.
I once read that in general, most compiles will only inline ''one''
level.
IE: if all the following methods were declared/defined as inline in
their respective classes, can I expect the compiler to try and inline
them all?
obj.GetSize()
{
a.GetLen()
{
b.GetHead();
{
c.CreateIterator();
I''m sorry if this is hard to understand visually. I''m just trying to
depict they the code would be logically ''copied'' and embedded at
successive levels of the call stack.
<offtopic>
If I were more adept at GDB, or Visual Studio - I''d prefer to look at
the resulting ASSEMBLY to see for myself what it did. Maybe I can
execute the app in DEBUG mode and open the disassembly window - but
would that jump to the method declarations? I''m not as facile at
ASSEMBLY of the debugger as I wish. Suggestions or general rules?
</offtopic>
Contextually, I have written a wrapper class for a library that is
essentially composed of ''pass through'' calls.
IE: I''ve created a C++ class interface over a set of C library calls.
struct GuiHelper
{
inline void SetWindowPos(int, int, int, int)
{
::SetWindowPos(...);
}
}
And I''m worried (per that article I seem to remember seeing) that if I
use any of these methods in my other functions - that I will have used
up my ONE inline call per function stack. In other word, if I use
these methods in other, inline calls, when will the compiler be apt to
eventually quit inlining things?
Quantitatively then, is judicious inlining important? or can I willy
nilly declare/define all very small tight methods as inline and be
confident that several small inlined methods calling each other will
likely, all be inlined.
--note: this also goes for Setters and Getters. I''m afraid of
supplying getX or getY methods for fear that anywhere they will be
used - they will use up the ONE level of inlining the compiler will
create - and consequently, might not be the best method of the stack
to have inlined.
Thanks in advance for any insight,
-Luther
LuB wrote:How judicious ought one be when inlining small methods.
Keep in mind that inline is just a hint to the compiler. The compiler
has the freedom to choose either inline or not inline the specified
subroutine.
If your profiling indicates that inlining a subroutine can significantly
improve application performance, consider adding ''inline'' declaration.
Fei
On Mar 30, 11:42 am, Fei Liu <fei...@aepnetworks.comwrote:LuB wrote:How judicious ought one be when inlining small methods.
Keep in mind that inline is just a hint to the compiler. The compiler
has the freedom to choose either inline or not inline the specified
subroutine.
If your profiling indicates that inlining a subroutine can significantly
improve application performance, consider adding ''inline'' declaration.
FeiYes, I do know that it is just a hint.
Assume I am writing a library for someone else to use.
And, assume my classes in turn, wrap up some other library (MFC, WTL,
take your pick). I am essentially wrapping up some library ... writing
pass through calls ... and then handing the resulting class to someone
else. Maybe selling it someone else.
Will I be hurting someone else''s code - by declaring and implementing
as "inline" all the simple, one line pass through operations in my
library.
-Luther
LuB wrote:On Mar 30, 11:42 am, Fei Liu <fei...@aepnetworks.comwrote:>LuB wrote:>>How judicious ought one be when inlining small methods.Keep in mind that inline is just a hint to the compiler. The compiler
has the freedom to choose either inline or not inline the specified
subroutine.
If your profiling indicates that inlining a subroutine can significantly
improve application performance, consider adding ''inline'' declaration.
Fei
Yes, I do know that it is just a hint.
Assume I am writing a library for someone else to use.
And, assume my classes in turn, wrap up some other library (MFC, WTL,
take your pick). I am essentially wrapping up some library ... writing
pass through calls ... and then handing the resulting class to someone
else. Maybe selling it someone else.
Will I be hurting someone else''s code - by declaring and implementing
as "inline" all the simple, one line pass through operations in my
library.
-Luther
How can it hurt someone else''s code? Inlining only happens at link
time...What makes you think it might hurt someone else''s code?
这篇关于过度内联的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
